Hacker News new | ask | show | jobs
by dassurma 1892 days ago
Author here!

You even included in the quote: It’s important to warm-up the code is so you don’t measure a mixture of performance characteristics between interpreted JS and compiled jS. How long the warmup takes is _incredibly_ device dependent, so instead I measured Ignition and SparkPlug independently so you get a feel for the speedup. I did not discard that at all in the comparison.

4 comments

My mistake if you are actually including the warm up times in the benchmarks, I misunderstood. Arguably, single-execution-from-scratch JS vs WASM benchmarks could have even more value than repeated, warmed-up benchmarks as the former simulates a common web use case. IMO you _should_ very well end up measuring a mixture of the performance characteristics of interpreted JS and optimized machine code if that represents common use.
It is indeed in the earlier benchmarks, but:

* It's not in the later ones

* You present TurboFan performance as the speed of JavaScript. e.g. your tables present JavaScript with Ignition as ~40x slower than JavaScript in certain test runs.

Will be this on the next HTTP 203?
It's a fantastic analysis, and I am a bit surprised by some of the results. Thanks for doing the work and putting together a great resource.

kodablah's point is a valid one generally. A parallel post notes that a developer can't avoid the warm-up time, but they can by using WASM.

As an aside, does v8 cache the optimized native code to any degree? I know there is code caching in the major browsers to presumably avoid reparsing Javascript, but if I had a theoretical page with say an image blur function, would each visit/load go through the same analysis/optimization process, going from slow to fast?

I imagine such caching is slowly being phased out because it can be used to create 'super-cookies'. That is, you can fingerprint a user by detecting whether certain bits of javascript are or aren't cached. (Detection of being cached is just a matter of measuring execution time).
It _is_ cached, but the wasm binary itself as well as the optimized version to improve startup times. The cache however is per origin. So no other origin can make use of the cache which prevents the fingerprinting aspect.