February has been an exciting and very, very busy month for me. As you have probably heard, we’ve finally announced that we will launch the Ignition+TurboFan pipeline in Chrome 59. So despite running late, and not making it for February actually, I’d like to take the time to reflect on the TurboFan tale a bit, and tell my story here. Remember, that everything you read here is my very personal opinion and doesn’t reflect the opinion of V8, Chrome or Google.
Over the last couple of months the V8 team focused on bringing the performance of newly added ES2015 and other even more recent JavaScript features on par with their transpiled ES5 counterparts.
Not a lot happened behind the scenes of V8 since the December Edition due to holidays and planning for 2017, so this is going to be a brief article. The most exciting V8 event for the web world was probably turning on the flag for WebAssembly by default in Chrome M57 and Node 8.
Following up on what I promised earlier here's another edition on what's going on behind the scenes of V8 as we are approaching the end of the year. A lot of cool stuff happened in V8 in 2016, probably most importantly that we are changing the focus of V8 to treat Node.js as a first class citizen (similar to Chrome) and moving away from measuring performance only via traditional JavaScript benchmarks to measuring actual performance of real world web pages via tooling built into the browser.
Following up on my latest blog post on the truth about traditional JavaScript benchmarks here are a couple of comments I'd like to address. First of all, I'm over-exaggerating quite a bit with the intention to actually trigger a discussion, for example not everyone hated JavaScript with passion before 2007, there were quite a few developers who already used it daily and who were excited to have a tool that just get's the job done (for publishing on the web). Also JavaScript is certainly not the only important technology in software engineering these days, there are many important technologies that have nothing to do with JavaScript. Nevertheless speaking of the overall impact, JavaScript is probably the top item currently, and here's why:
It is probably fair to say that JavaScript is the most important technology these days when it comes to software engineering. To many of us who have been into programming languages, compilers and virtual machines for some time, this still comes a bit as a surprise, as JavaScript is neither very elegant from the language designers point of view, nor very optimizable from the compiler engineers point of view, nor does it have a great standard library. Depending on who you talk to, you can enumerate shortcomings of JavaScript for weeks and still find another odd thing you didn't know about. Despite what seem to be obvious obstacles, JavaScript is at the core of not only the web today, but it's also becoming the dominant technology on the server-/cloud-side (via Node.js), and even finding its way into the IoT space.
So this is my attempt to start a series of blog posts about what's going on behind the scenes of V8 in order to bring more transparency to what we do for Node.js and Chrome, and how this affects developers targeting either Node.js or Chrome. I'll mostly talk about stuff where I'm actively involved, so mostly things that are related to JavaScript Execution Optimization, new language features and a few tooling/embedder related issues.
For the last couple of months we - together with some awesome Emberfolks - have been hunting a terrible bug in V8, that I used to call "the Ember issue", because this bug especially affects websites based on the Ember.js framework. Ember.js was never really great in Chrome - i.e. there have been reports of serious performance problems in 2013 already, when I had just joined the V8 team - but it seems like it got worse recently, leading to increased load time and pretty serious jank - up to two second pauses - even though we spent a lot of resources on techniques like the Idle-Time Garbage Collection Scheduling and other jankrelated improvements that should avoid exactly these problems.
As mentioned in my previous blog post about a new approach to Function.prototype.bind there's more potential for optimizing bound functions in V8, especially in the new optimizing compiler TurboFan. One obvious thing here is to further reduce the overhead for calling into bound functions, which was traditionally very high.
The performance and compatibility of Function.prototype.bind and the resulting bound function objects has traditionally always been an issue in V8 (and thereby in Chromium based browsers and Node.js driven servers).