June 22, 2016 10:00 am

JavaScript performance updates in Microsoft Edge and Chakra

By / Program Manager, Chakra

Since we first started work on the Chakra JavaScript engine, it has been our mission and priority to make JavaScript faster for the real-world web, and to continuously improve the experience of browsing in Microsoft Edge (and previously Internet Explorer). We’ve had a very busy year, with highlights like taking Chakra open-source, delivering ES2015 & beyond, experimenting with WebAssembly and more!

Through all of this, performance remains a principal theme – our team regularly looks at customer feedback and telemetry data to find potential patterns that slow down user experience, and tunes Chakra to provide substantial boosts to the web. Today, we’d like to share a few recent Chakra improvements coming up in the Windows 10 Anniversary Update, which you can preview today on recent Windows 10 Insider Preview builds.

Memory optimizations in functions

One of the code patterns on the web is the abundance of small-sized functions in scripts. This isn’t particularly a surprise as it is common developer practice to break down complex coding logic into many smaller pieces. The practice reduces repetitiveness and makes reading, debugging and testing the code much easier. Even better it can have a performance advantage, as smaller functions are generally easier to inline and the profiler can target the ‘hottest’ ones to produce JIT’ed code.

To optimize for this pattern especially in terms of memory consumption, Chakra has refactored the metadata format used for each function (internally referred to as FunctionBody). Based on data, pointers in FunctionBody that point to rarely-used information have been moved to a dynamic auxiliary structure and will not be instantiated and consume memory unless necessary. A good example is the asm.js-related data which is not applicable for most functions. Most of the 32-bit counters in FunctionBody were also observed to rarely have values over 256, such as the variable count or object literal count within a function. Thus these counters have been replaced by a compact structure that uses a single byte for each counter and those counters can be promoted to full 32-bit values if needed. Combined with a good number of functions, these seemingly subtle optimizations can make a big difference in reducing memory overhead (we’ll share our experiments later).

Diagram showing pointers and counters in FunctionBody moved to memory-saving structures

Many pointers and counters in FunctionBody have been moved to memory-saving structures

Deferred parsing for event-handlers

The modern web is a very interactive place, and inside almost every page there lies an event system with plenty of event-handlers defining the behavior of button-clicks, mouse-overs and many other events. However, unless the associated events are triggered, event-handlers are basically dead code. And in fact more often than not many of them end up unused during a browsing session. Just think about how many buttons or textboxes you left untouched the last time you visited your Facebook home page and imagine these controls and others all have event-handlers associated with them. Taking advantage of the formerly introduced deferred-parsing feature, Microsoft Edge and Chakra now delays the full parsing and bytecode generation of event-handlers until they are first called. Chakra uses a smaller representation for partially-parsed handlers, so the optimization not only improves the start-up time but also saves memory from any unused handlers.

The combination of deferred parsing for event-handlers and the memory optimizations in FunctionBody can together shrink a fair amount of memory footprint for each page. Though the actual savings depend highly on the pages being loaded and thus is quite hard to generalize, our experiment on a small sample of top-visited sites shows that these optimizations along with other smaller tweaks typically reduce about 4% to 10% of memory usage per page opened in Microsoft Edge, with cases where the savings reach over 20%.

Synthetic JavaScript benchmarks

All of our performance efforts are driven by data from the real world web and aim to enhance the actual end user experience. However, we are still frequently asked about JavaScript benchmark performance, and while it doesn’t always correspond directly to real-world performance, it can be useful at a high level and to illustrate improvement over time. Let’s look at where Microsoft Edge stands at the moment, as compared to other major browsers on two established JavaScript benchmarks maintained by Google and Apple respectively. The results below show Microsoft Edge continuing to lead both benchmarks.

Chart comparing browser performance on Google Octane and Apple Jetstream benchmarks.

All measures collected on 64-bit browsers running 64-bit Windows 10 Anniversary Update (1607)

We are very excited to share our performance effort to reduce memory footprint and start-up time with you. The road to better performance never ends, and we’re as committed as ever to making JavaScript faster. There will be more improvements in the summer months, so stay tuned for additional updates! Until then, we love feedback and rely on it to help us improve. You can always get in touch on Twitter via @MSEdgeDev and @ChakraCore, or the ChakraCore repo on GitHub.

Limin Zhu, Program Manager, Chakra Team

Updated October 31, 2016 2:19 pm

Join the conversation

  1. Really impressed and appreciate the work that the team has done to improve Chakra.
    That said, I’d love to see more improvements in MS Edge outside of Chakra. We all know Chakra is fast, but javascript was never the slow part of a browser and it means the investments should go elsewhere. Rendering on Edge (and windows 10 in general) is still terrible, and Edge’s dev tool is sub par compared to those in Chrome and Firefox. Until those areas are improved, it’s still impossible for Edge to gain users’ and devs’ traction.
    Just my thoughts 🙂

  2. Good deal, Limin, this is good to hear.

    I did want to warn you: as time has gone on (and especially the past week or so), my Edge browser has felt increasingly sluggish. It has been hanging up on Web pages (even Facebook!), becomes unresponsive, and sometimes even fails to open.

    This *never* happened previous to this month.

    Keep up the good job, but some of us really appreciate a lightweight and fast Web browser that doesn’t need a million add-ons to complicate things.

  3. You have developed such a great piece of software! Why don’t you distribute it to other OSs, like other web browsers do? I have Windows 7 and I can not use Edge 🙁

  4. Chakra is an excellent JS engine and it’s good to see it improve, but what about performance improvements to the DOM engine, especially DOM mutations? It seems like this is where Edge lags behind other browsers, both in synthetic and real world measures.

  5. Hey,

    I’ve found a bug in IE11 on Windows 10.. assigning a random stylesheet (style.css) under Settings -> Accessibiliyg -> Custom Style sheet (with the use website font size/styles unticked) results in constant crashing on IE11.

  6. Really impressive. Delayed execution is a stroke of genius.. I just hope you’re not delaying the parsing/compiling of the window scroll event handlers as they need to be ready from the instant the page renders. I’ve noticed a number of sites in the past few insider builds that normally lock elements the top of the viewport when you scroll past them tend to let them scroll out of view before they lock a bit later (sometimes several seconds later). Works fine on Chrome/FF. It’s as if the scroll event isn’t triggering right away. Or maybe that’s a separate issue?

  7. Glad to see such improvements, it will benefit Edge users eventually, but I would like to know when they will be merged into Edge. Chrome has about://version to know its v8 version, is there a similar approach to know ChakraCore version in Edge browser? thanks

  8. Hi, this is very nice, however in practice it is not so cool:

    The demo, classic WebGL application using one single canvas:
    Chrome MacBook – 48 FPS
    MacBook Pro 15, Mid 2014, Intel Core i7-4870HQ 2.5 GHz, NVIDIA GeForce GT 750M 2048 MB
    Chrome Win10 – 32 FPS
    Edge Win10 – 8 FPS
    PC: i5-3330 – 3.0-3.2 + R9-285-GAMING-2G + Fresh Window 10 Anniversary Update install + Lastest AND Dx12 drivers

    This is very sad

  9. I have 30700 in Edge, 30400 in Chrome, 29000 in FX and 16400 in IE11…

    All tests in Win 10 15002 with latest version for Chrome and FX.

    Propaganda ? Because being 300 points above… 1/100 gain… good…