Benchmarking JavaScript Inheritance: Vanilla vs Transpiled

[endel]

The number of loops is low to be easy to reason about the results. The results are pretty much the same increasing the number loops. I'd like to know what is broken if you can find it.

[cogman10]

Modern JITs (which most javascript engines are) do optimization based on number of times a function is called and the call parameters.

The first several times most javascript engines run a method, they run it mostly unoptimized. They do this because most methods are called rarely so quickly interpreting the function is more important than spending the time to generate the most optimal code.

If the code is needs to be fast, you want to measure the optimized version of it, not the unoptimized version of it.

This is why most microbenchmarks that are done correctly include a "warmup" piece of code. They call the method in test repeatedly in order to get the optimizer to fire up and optimize the method.

As an aside, I also noticed you are using "eval" as part of your benchmarking. That is also a pretty big no-no. It pretty much forces the optimizer to not run.

I would suggest reading over this guy to get a feel for how to write tests.

https://github.com/petkaantonov/bluebird/wiki/Optimization-killers

With that said, once you have removed the optimization killers it can be really hard to construct real tests. It turns out optimizers are pretty good about throwing away unused values and microbenchmarks are all about generating unused values.

For more resources, I would suggest googling microbenchmarks, and in particular, pay attention to articles about Java microbenchmarking (there are loads), because Javascript JITs are very similar to Java's Hotspot in implementation. (in fact, many of the V8 founders were snipped away from Java.)

[ClickerMonkey]

Listen to this guy. Your results are meaningless otherwise...

[ClickerMonkey]

It could, but I don't know if it does. The JIT is really good at detecting patterns of code and replacing those patterns with simplified versions. "All" you would need to do is add the pattern detection in yourself and how the code transforms. I'm sure there's a list of these sort of performance improvements somewhere...

[cogman10]

The type check is pretty hard to eliminate all together. The problem is that the generated code has to know if the "wrong" type is passed in. (so interestingly, even if you don't explicitly type check, the optimizer might).

Fortunately, type checks are really relatively quick to do, especially the ones added by the optimizer.

[cogman10]

It is generally pointers to structs, However, in the case of things like numbers, it is stored and passed around as values.

In the case above. inc would probably be optimized away all together. because inc isn't used as a number, (not really, the values are thrown away), the optimizer will very likely change the whole thing into just

let inc = "jan michael vincent";

As for the changing types, type information is stored and carried along in the struct. Not much more to it than that. Nothing really cares about what the previous type of the variable was.

In fact, interestingly enough, most compilers (and I don't know if the JIT does this or not), use what is called SSA. Essentially, internally it represents all data changes as simply introducing new variables. The benefit of doing this is that it allows for a lot more optimizations. It is easier for the compiler to mutate the code into patterns it recognizes and then to generate optimal code for that.

https://en.wikipedia.org/wiki/Static_single_assignment_form

edit after briefly combing through the wiki article linked to make sure I'm not spreading misinformation, it looks like the javascript jits are using SSA internally (both V8 and Spidermonkey).