Windows 10: Improved JavaScript and WebAssembly performance in EdgeHTML 17

Brink · Jun 19, 2018

In every release of Microsoft Edge, we tune the Chakra JavaScript engine to provide better startup and execution performance, with a leaner memory footprint, and with improved responsiveness on real-world workloads.

As EdgeHTML 17 rolls out to users as part of the Windows 10 April 2018 Update, we’d like to dive into some of the optimizations we’ve made in the Chakra engine in this release. These ongoing optimizations can have a dramatic impact on the day-to-day browsing experience for end users, resulting in faster sites and web apps.

Leaner memory footprint

(Re-)defer parsing for arrow functions and object literals methods

Over the past two Windows releases, we have been improving Chakra’s defer- and re-defer-parsing pipeline, allowing pages to start up faster while consuming less memory.

When given a script, Chakra performs a quick pre-parse check for syntax errors and defers the full parsing of any eligible function until it is first called. Re-deferring happens at a later point when Chakra heuristics determines that a fully parsed function is unlikely to be called again, in which case Chakra releases the memory holding the metadata generated during full parsing and leaves the function effectively in a state as if it had been just pre-parsed and deferred.

In EdgeHTML 17, we have continued to invest in this pipeline, and extended the list of functions eligible to include arrow functions and methods on object literals.

1
2
3
4
5
6
7
8
9
10 // parsing of these functions are deferred until called
// arrow functions
let addOne = (x) => {x + 1};

// object literal methods
let john = {
name: 'John Doe',
get name() {return this.name},
greet() {console.log('Hello')}
};
The impact of this change can vary depending on the sites, but our early experiments show an average memory savings of 7% on from this and a few other memory improvements in EdgeHTML 17.

RegExp bytecode refactoring

Many Microsoft Edge users rely on extensions for ad blocking and related scenarios to control their experience while browsing the internet. Some ad blocking extensions are built using a considerable amount of RegExp logic, which motivated us to make a series of bytecode refactoring changes for a leaner experience when running with these extensions enabled in Microsoft Edge.

Most significant among those changes is that Chakra condensed RegExp opcodes from 4 bytes to 1 and packed the structs. While the consequential unalignment might imply a performance slowdown, data collected on various scenarios indicates that it shouldn’t cause any visible performance regression.

As a result of this refactoring, Chakra was able to reduce RegExp bytecode memory in some popular extensions in this release by up to 10%, savings that should be reflected in other apps or sites using RegExp as well.

Faster JavaScript built-ins

In addition to memory savings, EdgeHTML 17 brings improvements to several JavaScript built-ins, building on optimizations initially enabled in EdgeHTML 16.

Type sharing for Object.create

Object.create is used to support JavaScript inheritance and null is also often tossed in to create a lean and mean dictionary/property bag. Chakra has an internal type system, and each object in Chakra is represented with an internal dynamic type. Many Chakra optimizations depend on objects with similar layout sharing types with each other. For example, inline caches can store fast paths for various types encountered at call sites, and objects with the same or an equivalent type are able use the same fast path as the cached type.

Type sharing between {x: 1}, {x: 2, y: 2}, {x: 3, z: 3}

Previously, however, objects created by Object.create were associated with a special nulltype handler in Chakra that cannot share types with other objects, so these optimizations didn’t apply to objects created using Object.create.

1
2
3
4
5
6
7
8
9
10 let dict1 = Object.create(null);
let dict2 = Object.create(null);
let dict3 = Object.create(null);
dict1.x = 1;
dict2.x = 2; dict2.y = 2;
dict3.x = 3; dict3.z = 3;
// because Object.create cannot share types, o.x in 2nd/3rd calls are cache misses
foo(dict1);
foo(dict2);
foo(dict3);
Beginning with EdgeHTML 17, Object.create returns objects with sharable types. Object.create(Object) now has the normal Object type, and Object.create(null)uses a new null type handler sharable with other Object.create(null) and compatible objects. dict1, 2 and 3 in the above example can now share types and have equivalent types, hence o.x in foo(dict2) and foo(dict3) are cache hits. This change results in an up to 25% speedup in some AngularJS workloads.

Polymorphic inline cache for Object.assign

Object.assign is an ES2015 feature often used to merge or clone objects. In EdgeHTML 16, we improved bracket access (o[prop]) by deploying polymorphic inline cache, which is able to cache multiple types and their associated fast paths at a given call site. With EdgeHTML 17, we’ve propagated the same optimization to benefit Object.assign, which upon de-sugaring involves a sequence of o[prop] style calls.

1
2
3
4
5
6
7
8
9
10
11 // an illustrative Object.assign polyfill
function assign(target, ...sources) {
sources.forEach(src => {
for (let prop in src) {
// multiple types and fast paths can now be cached at target/src call sites
// therefore improves Object.assign performance
target[prop] = src[prop]
}
});
return target;
}
This simple optimization results in a roughly 2% improvement in some React/Redux workflows, and we expect to further improve performance for this pattern in the next release.

JSON.parse/stringify optimizations

JSON.parse and JSON.stringify are your handy JSON serialization tools in JavaScript. Interestingly, it is also a fairly common pattern to make nested JSON.parse(JSON.stringify(obj)) calls to clone data objects.

Previously, Chakra implemented JSON.stringify by first scaning the object to be serialized, creating the necessary metadata, allocating a large enough buffer for the output string, creating intermediate sub-strings (for each quote, comma, key, value, etc.), and concatenating them together one-by-one.

The creation of intermediate strings caused a lot of redundancy in terms of both time and memory, so in EdgeHTML 17, Chakra skips creating those substrings altogether, and also delays filling up the output string from the metadata until it is actually needed. In the case of a JSON.parse(JSON.stringify(obj) call, the serialized object string is never actually created, and Chakra is able to construct the output object from the metadata generated during stringify.

1
2
3
4 let obj = {a: 1, b: 2};
let str = JSON.stringify(obj); // scans obj & create metadata
let objClone = JSON.parse(str); // re-construct obj from metadata, no string created
console.log(str); // JSON string creation is delayed until here
This change leads to JSON.stringify being roughly 40% faster in internal performance tests and roughly 70% faster for nested parse/stringify calls.

Rewriting Array Iterators in JavaScript and faster for...of

For…of performance on array also received a major boost in the EdgeHTML 17, and is up to 2.5x faster according to our testing. This speedup is achieved through rewriting the C++ Array Iterators implementation in JavaScript.

We had contemplated a feature rewrite in JS before―many JS optimizations didn’t apply to the C++ implementation, plus next() calls in C++ allocate objects on the heap, which is more expensive than JS stack allocation. The major challenge with a JS implementation is that de-sugared for…of involves a try/catch/finally block to handle cases of abrupt completion, which would have disabled most Chakra optimizations.

To work around those limitations, we made efforts to turn on JIT optimizations for functions with try/catch/finally in EdgeHTML 16, and later enabled inlining for the same as well. With those pre-requisites in place, we were able to rewrite for...of in JS, which runs much faster on non-excepting path.

WebAssembly

Microsoft has been working closely with the WebAssembly Community Group (CG) to evolve this growing technology, and we shipped the WebAssembly MVP last year in EdgeHTML 16.

In EdgeHTML 17, WebAssembly (and asm.js) gets even faster with inlining support, which speeds up the workloads we’ve been tracking by about 4.5%. For ChakraCore embedders, WebAssembly is not only available on Windows, but also on Linux and MacOS, as we fixed calling convention issues.
A number of new and exciting WebAssembly features are being discussed within the CG, such as threads, reference types (for host interop), and ES modules integration. We look forward to continuing to collaborate with the CG to move this technology forward and to landing additional features as they progress on the standards track.

Get involved!

It’s always exciting to share more about performance enhancements to Chakra and Microsoft Edge. As always, we’ll continue to make enhancements in future releases, and your feedback is one of the key signals for us to decide what to do next.

We encourage you to dive in and try out these improvements for yourself, and be sure to share your thoughts with us on the ChakraCore repo, or via @MSEdgeDev and @ChakraCore on Twitter!

– Limin Zhu, Program Manager, Chakra
Click to expand...

Source: Improved JavaScript and WebAssembly performance in EdgeHTML 17 - Microsoft Edge Dev Blog

:)

Brink · Jun 19, 2018

WebAssembly support now shipping in all major browsers

While Mozilla has been preparing to launch Firefox Quantum, its fastest browser yet, some notable developments have happened with WebAssembly, the binary file format (“wasm”) that works with JavaScript to run web applications at near-native speeds.

In the past weeks, both Apple and Microsoft have shipped new versions of Safari and Edge, respectively, with support for WebAssembly. Since Mozilla Firefox and Google Chrome already support WebAssembly, that makes all four major browsers capable of running code compiled to the wasm format on the web.

“Google, Apple, and Microsoft had all committed to supporting WebAssembly in their browsers. To have that support in market today is a really exciting development,” said Luke Wagner, the Mozilla engineer who created WebAssembly’s precursor, asm.js, and spearheaded work on the WebAssembly specification.

For developers, broad client support means they can experiment with WebAssembly with assurance that most end users will be able to run super-fast wasm modules by default. Ubiquitous client support fueled the early success of asm.js. Since it is a pure subset of JavaScript, asm.js can run in any browser without modification. For instance, you can find asm.js on Facebook, where it powers popular games like Candy Crush Saga, Top Eleven, and Cloud Raiders.

A Growing Standard

What’s the big deal about WebAssembly? First, it’s on its way to becoming an industry standard. It’s a proven way to run large, complex applications on the web. And it gives web developers a number of options they’ve never had before. For instance, now you can:

Take advantage of the compact wasm format to transmit files quickly over the wire and load them as JavaScript modules

Get near-native performance without using a plug-in

Write code that is both performant and safe, because it executes within the browser’s security sandbox

Have a choice of languages besides JavaScript, using WebAssembly as a compiler target for C and C++, with additional language support to come.

How It’s Used Today

WebAssembly has caught the interest of a wide swath of technical folks, because it brings predictable performance to the web platform — something that’s been exceedingly difficult to achieve with JavaScript alone. Gaming companies were early adopters of WebAssembly and asm.js. Epic and Unitywere first to put their industrial-strength game engines on the web without rewriting the C++ code bases in JavaScript.

Today, the use cases for WebAssembly and asm.js have grown beyond online gaming. As people experiment with the process of using the WebAssembly format and its cohort, the Emscripten compiler, they’re finding ways to move increasingly sophisticated applications to the web. Things like:

Co mputer vision

3D mapping – Altus platform, Google Earth

User-interface design

Language detection

Audio mixing

Video codec support

Digital signal processing

Medical imaging

Physical simulation

Encryption

Compression – zlib-asm, Brotli, lzma

Computer algebra

“Asm.js and WebAssembly were really no-brainers for the gaming industry, because they had all this investment in massive C++ programs that they didn’t want to rewrite for the web,” Wagner said. “Now we’re seeing people using WebAssembly for all kinds of new projects. So there’s this real promise that we will someday be able to run most any application on the web and have it perform just as it would if it were running locally on your PC.”

Want to learn more about WebAssembly? Developers can find resources on MDN Web Docs and on the WebAssembly.org project site.

Interactive Tools

You can also try out WebAssembly Explorer, an online tool which allows you play around with a C/C++ compiler and understand how WebAssembly code is produced, delivered, and ultimately consumed by the browser. Another online tool, WebAssembly Fiddle, lets you write, share, and run WebAssembly code snippets in the browser. For an even deeper dive, you can inspect WebAssembly binaries to understand how WebAssembly code is encoded at a binary level.
Click to expand...

Source: WebAssembly support now shipping in all major browsers - The Mozilla Blog

Brink · Jun 19, 2018

A peek into the WebAssembly Browser Preview

Following the introduction of asm.js, we have been working with other browser vendors including Mozilla, Google, Apple, along with the rest of the WebAssembly community group, to push the performance boundary of the web with WebAssembly. WebAssembly is a new, portable, size- and load-time-efficient binary compiler target, which promises near-native performance on the web.

As the community group comes close to consensus over the final design of the MVP (minimum viable product) release, we are pleased to share that the WebAssembly standard is in browser preview and invite the community to provide feedback on the WebAssembly design. We’re continuing to make progress towards a public preview implementation in Microsoft Edge, and today we’re excited to demonstrate WebAssembly in our internal builds.

The Browser Preview

The WebAssembly browser preview is effectively a release candidate for MVP, and includes the latest:

Binary format, generalized from previous AST formats to a more efficient stack machine format; a more compact binary format generally means better loading time.

Equivalent human-readable text format for the purpose of reading, debugging, and occasionally handwriting WebAssembly.

Built-in JavaScript APIs to integrate WebAssembly modules to the web platform.

Up-to-date tools to produce WebAssembly modules, such as the Emscripten /Binaryen toolchain to convert C++ source to asm.js to WebAssembly, and WABT to convert between text and binary format.

To give you a taste of what WebAssembly looks like now, here is an example C++ recursive factorial function with its corresponding WebAssembly:

C++ factorial WebAssembly factorial function body
binary | text int factorial(int n)
{
if (n == 0)
return 1;
else
return n * fac(n-1);
} 20 00 | get_local 0
42 00 | i64.const 0
51 | i64.eq
04 7e | if i64
42 01 | i64.const 1
05 | else
20 00 | get_local 0
20 00 | get_local 0
42 01 | i64.const 1
7d | i64.sub
10 00 | call 0
7e | i64.mul
0b | end The WebAssembly factorial function is extracted from the WebAssembly spec test.

We are eager to hear feedback from the community on WebAssembly. App authors should still expect changes and recompilation of apps for the MVP release, but any feedback from developing an app during the preview will help us make a better standard.

Implementation Progress in Microsoft Edge

We’ve been hard at work developing support for WebAssembly in Microsoft Edge at the open-source ChakraCore project repo. Microsoft Edge and ChakraCore are close to shipping the browser preview, which we expect to come when the full JavaScript APIs are implemented.

To demo the current capability of ChakraCore, we are also excited to showcase the AngryBots demo (with an updated WebAssembly binary) running in an internal build of Microsoft Edge. The demo loads faster than earlier versions compiled to asm.js or older WebAssembly formats, due to a more compact binary and ChakraCore’s new ability to defer parsing WebAssembly functions.

Over the next couple of months, our team will be focused on bringing the browser preview to Microsoft Edge. We look forward to continuing to contribute to the standardization of WebAssembly with the other browser vendors and the community, and would love to hear your thoughts about WebAssembly via @MSEdgeDev and @ChakraCore, or on the ChakraCore repo.

― Limin Zhu, Program Manager, Chakra
Click to expand...

Source: A peek into the WebAssembly Browser Preview | Microsoft Edge Dev Blog

Brink · Jun 19, 2018

Previewing WebAssembly experiments in Microsoft Edge

Last June, we announced the start of our journey towards implementing WebAssembly – a new, portable, size and load-time-efficient binary format suitable for compiling to the web. WebAssembly is a continuation of our previous efforts to support asm.js to bring a fast and safe compile target to the web. You can learn more about WebAssembly at the FAQ on GitHub.

Since then, we have been collaborating closely with Firefox, Chrome, WebKit and the community to keep the WebAssembly principles and design moving forward in the W3C Community Group. Today, we are excited to showcase an early preview of experimental WebAssembly support in an internal Microsoft Edge build with the AngryBots demo, alongside similar previews for Firefox and Chrome. Below is a video of the demo running in Microsoft Edge using the preliminary WebAssembly support in the Chakra engine.

[youtube]hSeB9I_mK6A[/youtube]

Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case.

With ChakraCore now open source, we have been developing our WebAssembly implementation entirely in the open in the WebAssembly branch of our ChakraCore repo on GitHub. Under the hood, our implementation is able to reuse much of the existing asm.js infrastructure. The WebAssembly code goes through the same pipeline as the asm.js code would, after it has been parsed.

We are excited about WebAssembly’s progress across browsers and will continue to partner with Firefox, Chrome, WebKit and the community to advance the design and bring the power of WebAssembly to the web and future Microsoft Edge releases. You can follow WebAssembly design and ChakraCore’s implementation as we make progress on this technology.

― Limin Zhu, Program Manager, Chakra
Click to expand...

Source: Previewing WebAssembly experiments in Microsoft Edge | Microsoft Edge Dev Blog

Windows 10: Improved JavaScript and WebAssembly performance in EdgeHTML 17

Improved JavaScript and WebAssembly performance in EdgeHTML 17

Improved JavaScript and WebAssembly performance in EdgeHTML 17

Improved JavaScript and WebAssembly performance in EdgeHTML 17

Improved JavaScript and WebAssembly performance in EdgeHTML 17 - Similar Threads - Improved JavaScript WebAssembly

Improve Performance For Minecraft

Improve Performance For Minecraft

trying to improve performance-

Improve performance

Improve performance on netbook

Performance Improvement Needed

New virtual machines with latest preview build of EdgeHTML 17 (17127)

Supercharging JavaScript performance with asm.js

Accessibility improvements in EdgeHTML 15

Users found this page by searching for:

microsoft edge optimise javascript wasm

edgehtml 17 bug fixes