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
to measuring actual performance of real world web pages via tooling built into the browser.
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
is certainly not the only important technology in software engineering these days, there are many important technologies that have
comes to software engineering. To many of us who have been into programming languages, compilers and virtual machines for some time, this still
point of view, nor does it have a great standard library.
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
a few tooling/embedder related issues.
For the last couple of months we - together with some awesome Ember folks - 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 jank related
improvements that should avoid exactly these problems.
performance recently, where performance means both peak performance (as in throughput of long running computations)
as well as user visible latency (as in time wasted not doing useful work towards completing a computation or rendering a
The Strato Linux V-Servers always reset their hostnames to
hXXXXXX.stratoserver.net on boot, no matter what you put in
/etc/hostname and there’s no way to fix this (it’s actually intended behavior). If you happen to have a Strato V-Server running Debian, here’s a simple failsafe way to fix the hostname early during boot and have all daemons use your desired hostname.