, delivering ES2015 & beyond
, experimenting with WebAssembly
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 hardly 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 can be promoted to full 32-bit 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).
Many pointers and counters in FunctionBody are 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 when 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 saving depends 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 saving reaches over 20%.
All measures collected on 64-bit browsers running 64-bit Windows 10 Insider Preview
System Info: Dell Optiplex 7010 Intel(R) Core(TM) i5-3475S CPU @ 2.90GHz (4 cores) 4GB ram
, or the ChakraCore repo on GitHub
, Program Manager, Chakra Team