-
i do a lot of JS benchmarking and whole-program measurement is key. sometimes optimization in one hotspot changes the whole profile, not just shifts the bottleneck to the next biggest thing in the original profile. GC behaves differently in different JS vms. sometimes if you benchmark something like CSV parsers which can stress the GC, Benchmark.js does a poor job by not letting the GC collect properly between cycles. there's a lengthy discussion about why i wrote my own benchmark tool for this purpose [1]. i can recommend js-framework-benchmark [2] as a good example of one that is done well, also WebKit's speedometer [3].
[1] https://github.com/leeoniya/uDSV/issues/2
[2] https://github.com/krausest/js-framework-benchmark
[3] https://github.com/WebKit/Speedometer
-
Civic Auth
Auth in Less Than 5 Minutes. Civic Auth comes with multiple SSO options, optional embedded wallets, and user management — all implemented with just a few lines of code. Start building today.
-
security-research-pocs
Discontinued Proof-of-concept codes created as part of security research done by Google Security Team.
> This effort, along with a move to prevent timing attacks, led to JavaScript engines intentionally making timing inaccurate, so hackers can’t get precise measurements of the current computers performance or how expensive a certain operation is.
The primary motivation for limiting timer resolution was the rise of speculative execution attacks (Spectre / Meltdown), where high-resolution timers are integral for differentiating between timings within the memory hierarchy.
https://github.com/google/security-research-pocs/tree/master...
If you look at when various browsers changed their timer resolutions, it's entirely a response to Spectre.
https://blog.mozilla.org/security/2018/01/03/mitigations-lan...
https://issues.chromium.org/issues/40556716 (SSCA -> "speculative side channel attacks")
-
i do a lot of JS benchmarking and whole-program measurement is key. sometimes optimization in one hotspot changes the whole profile, not just shifts the bottleneck to the next biggest thing in the original profile. GC behaves differently in different JS vms. sometimes if you benchmark something like CSV parsers which can stress the GC, Benchmark.js does a poor job by not letting the GC collect properly between cycles. there's a lengthy discussion about why i wrote my own benchmark tool for this purpose [1]. i can recommend js-framework-benchmark [2] as a good example of one that is done well, also WebKit's speedometer [3].
[1] https://github.com/leeoniya/uDSV/issues/2
[2] https://github.com/krausest/js-framework-benchmark
[3] https://github.com/WebKit/Speedometer
-
i do a lot of JS benchmarking and whole-program measurement is key. sometimes optimization in one hotspot changes the whole profile, not just shifts the bottleneck to the next biggest thing in the original profile. GC behaves differently in different JS vms. sometimes if you benchmark something like CSV parsers which can stress the GC, Benchmark.js does a poor job by not letting the GC collect properly between cycles. there's a lengthy discussion about why i wrote my own benchmark tool for this purpose [1]. i can recommend js-framework-benchmark [2] as a good example of one that is done well, also WebKit's speedometer [3].
[1] https://github.com/leeoniya/uDSV/issues/2
[2] https://github.com/krausest/js-framework-benchmark
[3] https://github.com/WebKit/Speedometer
-
No interest in a more general tool?
https://github.com/sosy-lab/benchexec
-
My old team at Google created a tool to help do better browser benchmarking called Tachometer: https://github.com/google/tachometer
It tries to deal with the uncertainties of different browsers, JITs, GCs, CPU throttling, varying hardware, etc., several ways:
- Runs benchmarks round-robin to hopefully subject each implementation to varying CPU load and thermal properties evenly.
- It reports the confidence interval for an implementation, not the mean. Doesn't throw out outlier samples.
- For multiple implementations, compares the distributions of samples, de-emphasizing the mean
- For comparisons, reports an NxM difference table, showing how each impl compares to the other.
- Can auto-run until confidence intervals for different implementations no longer overlap, giving high confidence that there is an actual difference.
- Uses WebDriver to run benchmarks in multiple browsers, also round-robin, and compares results.
- Can manage npm dependencies, so you can run the same benchmark with different dependencies and see how different versions change the result.
Lit and Preact use Tachometer to tease out performance changes of PRs, even on unreliable GitHub Action hardware. We needed the advanced statistical comparisons exactly because certain things could be faster or slower in different JIT tiers, different browsers, or different code paths.
We wanted to be able to test changes that might have small but reliable overall perf impact, in the context of a non-micro-benchmark, and get reliable results.
Tachometer is browser-focused, but we made it before there were so many server runtimes. It'd be really interesting to make it run benchmarks against Node, Bun, Deno, etc. too.
-
I once created this tool for benchmarking JS: https://github.com/xpl/what-code-is-faster
It does JIT warmup and ensures that your code doesn't get optimized out (by making it produce a side effect in result).
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
