Benedikt Meurer is a V8 engineer who writes about JavaScript engine internals, TurboFan, Ignition and performance benchmarks.
HN commenters recommend his post on traditional JavaScript benchmarks, and a former V8 engineer agrees that SunSpider is a poor benchmark that has misdirected performance work.
It can sometimes be difficult to predict what will cause performance regressions when developing an application or web server with test data. So you do your best with what you know at the time of release, and then deal with performance issues when you know what is causing regressions (e.g. saved searches) and can then make measurements and profiling to see what exactly is causing the issue.
Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).
There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).
There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.
JavaScript evaluation for example is…
Well, the optimizing pipeline has completely changed in V8 5.8 (if you use `--turbo --ignition`) and in 5.9+. It's been simplified and most importantly, does not deoptimize on quite so many common features (such as try/catch). More information at http://benediktmeurer.de/2017/03/01/v8-behind-the-scenes-february-edition/ and some of his other articles.
In my testing it appears that TurboFan cannot optimize certain patterns as well as Crankshaft did, but there's no reason to believe those regressions will remain as TF evolves. Optimizing more code is much more important for real apps.
Actually, the AOT optimization path for asm.js has been supported by Internet Explorer/Edge for quite some time. Chrome also supports AOT asm.js path now through their wasm implementation[1]. Before that Chrome and Safari did optimizations that just happened to make asm.js faster ;)
It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead.
[1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-december-edition/
Take a look at this talk on why mobile devices are so much slower than desktop devices ( they are indeed 10x slower in the traces I have looked at too) - https://youtu.be/4bZvq3nodf4
Also look at the speedometer benchmark (http://browserbench.org/Speedometer/) for a more realistic comparison of how slow your mobile device is compared to your desktop when running real world apps. Here are some numbers from the benchmark from some devices - http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks/#comment-3058874998
Speaking from the perspective of a (former) V8 engineer, SunSpider is crappy benchmark, and I can't believe people still track it. It has misdirected JavaScript performance engineering work for going on 15 years now, leading to all kinds of weird contortions in JavaScript engines that do not benefit real world sites.
Years ago, V8 switched away from microbenchmarks for the most part. See:
https://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks/
Woohoo!
I've been hoping that this guy's Function.bind optimizations land before 6.0: http://benediktmeurer.de/2015/12/25/a-new-approach-to-function-prototype-bind/
But you prompted me to check on the status of his work, and was happy to find a new post: http://benediktmeurer.de/2016/01/14/optimizing-bound-functions-further/
It looks like V8 will finally be able to inline bound functions (https://codereview.chromium.org/1581343002)! That's huge!