As with everything else in the Windows 10 Creators Update, Microsoft's Edge browser is also getting some welcome attention, with WebRTC 1.0 and Web Payments support, as well as blocking of Flash content by default. That however, is not all the latest major update for Windows 10 brings to Edge.
Post Creators Update, we are working on addressing an existing limitation of re-deferring to handle arrow functions, getters, setters, and functions that capture lexically-scoped variables. We expect to see further memory savings from the re-deferring feature.
The next improvement concerns the creation of so-called heap arguments for functions with no formal parameters. The Creators Update brings further optimizations to JIT (just-in-time compilation) to "avoid the creation of heap arguments with the presence of formals as long as there’re no writes to the formals". As such, there is no need anymore to "allocate heap arguments objects for code", which is an optimization that's beneficial for about 95% of the sites out there.
Yet another area where changes have been implemented is minified code, which web developers use to "reduce the download burden on the client side". Though Chakra was initially optimized for UglifyJS, one of the most popular code minifiers out there, the Creators Update set of improvements targets the Closure compiler. If you use it, or minifiers with similar patterns, you can expect an improvement in performance of up to 15%.
Under the hood, Chakra defers parsing WebAssembly functions until called, unlike other engines that parse and JIT functions at startup time. We’ve observed startup time as a major headache for large web apps and have rarely seen runtime performance being the issue from our experiences with existing WebAssembly & asm.js workloads. As a result, a WebAssembly app often loads noticeably faster in Microsoft Edge.
As a way to test out the validity of this last claim, the Tanks! demo is provided for anyone curious enough to try it out.
In Shared Memory and Atomics, SharedArrayBuffer is essentially an ArrayBuffer shareable between threads and removes the chore of transferring data back and forth. It enables workers to virtually work on the same block of memory, guaranteeing that a change on one thread on a SharedArrayBuffer will eventually be observed (at some unknown point of time) on other threads holding the same buffer.
In essence, it's the web equivalent of a program using multiple available threads, rather than a single one. This is, of course, in a quest to always improve performance.
All in all, a pretty sizeable update for the built-in browser.