[dcherman]

So I watched that and heard that you used BenchmarkJS which I believe intentionally prevents optimization from occurring, otherwise many tests would just end up being optimized away. Have you considered how function inlining might affect your results versus benchmarks like you ran in the video? Have you profiled them side by side under actual usage?

"Anonymous" function calls (function expressions, either immediate or not) are generally only more expensive because they're re-created all the time. Sometimes this is necessary to create a closure, often it's not. If you were to profile `var foo = function() {}`, performance should match the function declaration variant identically, so it's not the method of declaration that affects performance.

[marknadal]

That is something I have been suspecting of BenchmarkJS, which is unfortunate because I am/wasn't expecting to be responsible for building a better benchmarking tool (we are already building a database and a distributed testing framework).

FireFox does inline, and we can tell even with BenchmarkJS, which is why I think V8 wasn't (although it has improved significantly recently).

We ran an "actual use" test that saved 100M+ records a day for $10 total (on about 100GB+, processing, storage, backup). However since it is an "actual use" we don't know if inlining happened or not (I still suspect not, since I haven't seen that in V8 - but again, maybe that is BenchmarkJS killing it, despite seeing it in FF).

Correct correct. The function call is still expensive (anonymous or not), and managing scope is extremely expensive. You are on top of this stuff! Sounds like you do performance testing regularly?

[dcherman]

I do, but it's also easy to sound smart when you're standing on the shoulders of very smart people. @jdalton and @petkaantonov are two that I've regularly followed and read their code for learning purposes. IRHydra by @mraleph is a great tool for learning about V8 internals and examining what's going on under the hood. Bluebird is an amazing example to follow if you really want to optimize, however the vast majority of libraries and apps don't need to concern themselves with some of the crazier optimizations that are performed there.

The biggest takeaways that I've had are mainly that if you really want to optimize, then write the kind of code that the various engines can optimize best. With that in mind, TypeScript is not only a great language, it's actually a great performance tool since it can help you to identify polymorphic functions that maybe could be changed to monomorphic ones if they're in the hot path.

I've got another fun hacky kind of optimization for you though that I've mainly used for benefit in some angular code/expressions that are executed potentially millions of times. If you can make some assumptions about the name of the property being accessed for security reasons and it's going to be repeatedly used, compare the following:

// Setup

const makeGetter = (prop) => new Function("obj", "return obj." + prop");

const slowGetter = (obj, prop) => obj[prop];

const fastGetter = makeGetter("foo");

const obj = { foo: "bar" };

// Test

slowGetter(obj, 'foo');

fastGetter(obj);

This is primarily an optimization for Internet Explorer, but if I recall it was somewhat positive in other browsers at the time as well. It makes more sense if you consider it in the context of executing a simple angular expression repeatedly, though 1.6.0 might narrow that gap significantly now that the expressions sandbox was removed as I think they generate code similar to my "makeGetter" factory. Haven't re-tested yet.