Deno: Support high resolution timing for benchmarking code during runtime

[luvies]

Deno doesn't seem to currently support getting a fast, high resolution timestamp that can be used to time/benchmark code during runtime. The only method is to get the date in milliseconds (new Date().getTime()), but that would be slower and less accurate than a number explicitly used for tracking execution times.

[hayd]

Perhaps should add performance.now ? https://developer.mozilla.org/en-US/docs/Web/API/Performance/now

[luvies]

That seems like a good move forward, I think an implementation of the Performance class, with this included, would allow for a good performance tracking API that would be consistent with browsers. We could also consider an implementation using BigInt for added accuracy (possibly as an extension of this API)?

[kitsonk]

This is where it is implemented in Node.js: /src/node_perf.cc

Seems like a good/logical thing to add to me.

[sh7dm]

I'd like to work on it (performance.now)

[sh7dm]

Should we call it deno.performance.now() or just deno.now()?

[hayd]

It would be nice if performance.now had finer granularity, but this can be added in the future...

[luvies]

I suggested we have something that uses BigInt, however it would have to be a deno-unique thing since the Performance class doesn't provide anything that uses it. If someone can see a use-case, then I'd open a new issue for it

[hayd]

performance.now can be a float, it's in the spec. I think that should suffice for most cases? (E.g. send over us or ns bigint and convert to ms float for performance.now).

There's a bunch of other stuff in performance we should also look into.

[luvies]

Oh, I didn't mean that performance.now() should be a BigInt, just that something like performance.timestamp() (for example, name is absolutely up for debate) that returned a BitInt could be useful, since we support it in deno from the beginning. But I see what you mean, we only get milliseconds currently from the API, whereas the browser implementation does it as a floating point number (double precision I think). Apparently the spec says that it should aim for microsecond precision. Would it be worth re-opening this issue or creating a new one for that?

[kitsonk]

New one. The number also needs to be fuzzed to avoid encryption attacks as well. We can't be too precise actually. Just reliable.

[hayd]

Does it really need to be fuzzed? It does on the browser, but why deno?

On Firefox this is configurable (by default 2ms now), and you can use even larger granularity to avoid fingerprinting as a privacy setting.

[kitsonk]

The same reason, to avoid fingerprinting and potentially PRNG attack vectors. Fingerprinting a server is just as bad as a browser device. If we are serious about security, we should learn from others.

[luvies]

That seems reasonable, we should try to be as secure as browsers are, however since you have better control on the dependencies that are loaded on the server, would it be also reasonable to support a flag that enables high precision? That way you can do very high precision benchmarks or something like that when you need to, and leave it disabled in production.

[hayd]

I think passing high precision in the op, and the fuzz/round to 20us (or even 2ms) by default unless there is a flag passed seems reasonable. There are valid use case for precision timing.

[kitsonk]

Fuzzing in the runtime would be insecure... ;-) . While it is hard to get to the runtime op code, it isn't impossible.

I am not against high precision, but only as high precision as the browsers are.

[luvies]

That doesn't mean we can't have a flag that enables high precision without rounding, that just means we default to the rounding. The flag would be as secure as the others (e.g. --allow-read, --allow-write, etc), which is to say, very, very secure. It doesn't pose any more of a risk as those other flags do, which is why I think it might be worth considering adding to allow sandboxed high-precision benchmarking. I'll open an issue for the floating point number result from performance.now() and include this conversation in it.