
Traditional JavaScript benchmarks - ojno
http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks/
======
BlackFingolfin
"It is probably fair to say that JavaScript is the most important technology
these days when it comes to software engineering."

Uhh ... no?

~~~
sametmax
+1 "JS is the only API we currently have to use one of the most popular
plateform we have" would be more accurate. And it's a terrible API. I can't
wait for webassembly.

~~~
digi_owl
Could have sworn that webassembly is just a subset of JS.

~~~
Sean1708
You're thinking of ASM.js.

~~~
digi_owl
And the churn keeps on churning...

------
zspitzer
Is there a benchmark which tests boring real world usage? The web is littered
with people complaining about the performance of dynamically adding rows to
tables, especially in IE.

The good news is that the next version of Edge 15 has some really good DOM
performance improvements.

[https://developer.microsoft.com/en-us/microsoft-
edge/platfor...](https://developer.microsoft.com/en-us/microsoft-
edge/platform/issues/10152783/)

~~~
chrisseaton
But that's not the JS implementation - that's the DOM and layout
implementation. Faster JS won't improve that.

------
kalleboo
I apologize if this is an uninformed question, but are there any popular
_browser_ benchmarks out there? I'm sure that JS benchmarks are useful to
browser developers and those who want JS to be the next general application
platform, but as a user, I'm currently sticking to Safari since things like
battery life and scrolling performance on mainly document-oriented pages are
still more important to me.

~~~
hoschicz
the author mentions speedometer. It tests everything a browser needs to load
and use a web app - styling, DOM parsing, JS...

------
acqq
Some very good examples and a good explanation of the reasoning behind the
previous and the current optimizations of the JavaScript execution
infrastructure.

For the context, from the "about" page of the author, he:

"joined Google to work on the V8 JavaScript Engine in the Munich office,
where" he's "currently working as tech lead for the JavaScript execution
optimization team."

------
maaaats
The part about optimizing for the Mandreel-test by skipping some
initialization has gone full circle, as this is now exploited by developers.
[https://github.com/nolanlawson/optimize-
js](https://github.com/nolanlawson/optimize-js)

------
gravypod
All of these changes that the author is making are changes that the compiler
should be generating.

Unless you work in the embeded systems I don't expect people to have done or
needed the % 2048 trick.

~~~
sambe
The author is writing the compiler (and modifying it to make these changes).
What do you mean exactly?

~~~
gravypod
I'm just wowed by this not already being part of V8. What else have they been
doing?

I know that V8 has some amazing performance characteristics and if they aren't
from doing things that C compilers have been doing for years, then what are
these speed boosts coming from?

~~~
sambe
It might help to read a bit more closely. A lot of the optimisations being
discussed were already added years ago; the point is that they are not as
useful in real-world usage as they are in benchmarks (or, in fact,
disadvantageous).

JIT compiling a highly dynamic language is quite a different task than AOT
compiling a statically typed language. Bit-twiddling tricks are unlikely to be
the biggest concern. Try starting with the obvious like
[https://en.wikipedia.org/wiki/Just-in-
time_compilation](https://en.wikipedia.org/wiki/Just-in-time_compilation)

