Add benchmarks for db-level dispatch calls. #57
Conversation
These are novel in that the benchmark loop executes in JS space and each iteration calls into Rust and transfers the response back to JS. Example run: % ./tool/benchmark dispatch Hardware: 8-Core Intel Core i9 2.4 GHz, 32 GB RAM, 1 TB SSD dispatch::has 483 2,141,490 ns/iter dispatch::get1024 468 2,229,690 ns/iter 0.46 MB/s dispatch::get4096 459 2,273,355 ns/iter 1.80 MB/s dispatch::get16384 438 2,463,367 ns/iter 6.65 MB/s dispatch::put1024 100 23,429,150 ns/iter 0.04 MB/s dispatch::put4096 100 35,972,949 ns/iter 0.11 MB/s dispatch::put16384 100 57,210,150 ns/iter 0.29 MB/s dispatch::random4096 10855 108,412 ns/iter 37.78 MB/s
| wt.commit().await.unwrap(); | ||
|
|
||
| b.reset_timer(); | ||
| eval(&format!( |
There was a problem hiding this comment.
Little concerned about the use of eval (assuming that's what's happening under the covers here) deoptimizing.
There was a problem hiding this comment.
Very interested to hear more. What do you mean by that? And yes, this is using JS's eval to construct a benchmark of how long these functions take from a JS context. I should create a parallel copy of some of these that executes solely in wasm to isolate the difference that comes from the JS->wasm hop, but I'll wait for more feedback first.
There was a problem hiding this comment.
There are a lot of things js can do to accidentally trigger the jit to stop optimizing. i think eval might be one of those things. I don't know a lot about it, just to be wary of it. I'm not sure if it would just de-optimize this loop, or potentially what it's calling into like the marshaling code. @arv might know more.
There was a problem hiding this comment.
Basically I don't know if using eval() is a good simulation of somebody using the js library, but I know enough to know it's something to look at.
I guess you could find out the answer by running this in a browser and looking in the web inspector at the profiler. I know it marks functions that have been deoptimized:
There was a problem hiding this comment.
This eval looks fine since it is only used once at the top level of the computation.
There was a problem hiding this comment.
But if there is any kind of iteration of the rust function has then this is not going to be a realistic benchmark.
| (async _ => {{ | ||
| var array = new Uint8Array({}); | ||
| for (let i = 0; i < {}; i++) {{ | ||
| window.crypto.getRandomValues(array); |
There was a problem hiding this comment.
This should not be inside the benchmark. It is probably slow.
These are novel in that the benchmark loop executes in JS space and each
iteration calls into Rust and transfers the response back to JS.
Example run: