Benchmarking JavaScript • Vyacheslav Egorov • GOTO 2015
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about surprising JavaScript micro-benchmark results, to explain VM optimizations and benchmarking pitfalls.
Recommended by 3 people across 3 different months, 2015 to 2019.
What it is
A GOTO Chicago 2015 conference talk by Vyacheslav Egorov, a JavaScript performance expert on Google's Dart team, about how to benchmark JavaScript correctly. It covers why naive micro-benchmarks mislead given how modern JavaScript VMs optimize code.
What people said
Recommends Dinei · 2016-09 · Stack Overflow · on “Why does a needless IF clause increase the performance?”
As pointed out in the comments, this changes and results are so small that are meaningless. In 70k calls, you are getting just 171ms of difference, so this is probably result of some environment change, and not your code. If you run this benchmark 100 more times, the difference will change at every run (and can even increase), as response to changes in the environment. As "environment" I mean the computer that is running the benckmark, the network where the data is passing, etc. The computer is running other processes than you code, so if another process eats some CPU, your code runs slowly than before, and so on. To properly benchmark a code, you need to consider lots of thing more than jus
Recommends Seth Holladay · 2016-10 · Stack Overflow · on “Javascript Objects vs Map performance (Chrome, V8, Node JS)”
Your longest test case took less than 0.005 milliseconds. The computer is eating it for breakfast. You are in territory where microscopic fluctuations in cold boot time will drastically change the outcome as a relative percentage. That makes these numbers less meaningful. I would suggest optimizing for readability and other concerns. Make It Work, Make It Right, then Make It Fast [LINK] . Remember that Map is new and will get faster as the engines evolve. Here are some resources related to micro-benchmarks, pitfalls and ways to improve them. [this video] [LINK]
Recommends 1565986223 · 2019-05 · Stack Overflow · on “Why '===' is slower than comparing char by char when comparing two string in Nodejs”
I reversed the comparison operation and looks like 0 ms (sometimes 1 ms) on === (firefox). So probably something to do with compiler internals trying to optimize. Something like, hey the strings are the same in the second comparison operation and I've already compared them. So I'll re-use the result. This youtube video [this video] explains best. function createConstantStr(len) { let str = ""; for (let i = 0; i < len; i++) { str += String.fromCharCode((i % 54) + 68); } return str; } let str = createConstantStr(1000000); let str2 = createConstantStr(1000000); console.time('equal by char') let flag = true; for (let i = 0; i < str.length; i++) { if (str[i] !== str2[i]) { flag = false; break; } } con
Cites Vyacheslav Egorov · 2015-07 · Stack Overflow · on “What makes this function run much slower?”
Once you call test with two different functions fn() callsite inside it becomes megamorphic and V8 is unable to inline at it. Function calls (as opposed to method calls o.m(...) ) in V8 are accompanied by one element inline cache instead of a true polymorphic inline cache. Because V8 is unable to inline at fn() callsite it is unable to apply a variety of optimizations to your code. If you look at your code in IRHydra [LINK] (I uploaded compilation artifacts to gist for your convinience) you will notice that first optimized version of test (when it was specialized for fn = straight ) has a completely empty main loop. [LINK] V8 just inlined straight and removed all the code your hoped to bench