Ext JS 4.1 Performance Preview

Today we’re excited to release a preview of the performance improvements coming in Ext JS 4.1. We’ve been working hard over the last several months to dramatically improve load time, render and layout performance across the entire framework. For the last several months we’ve been benchmarking and performance tuning with our own examples as well as a number of your apps across a range of browsers, and we’ve made some significant improvements.

Today we’d like to open the current build up to everyone so you can see the speed increase in your own apps. We’d like you to test this release out with your own apps, but want to be very upfront about the nature of this build. This is a **pre-beta performance preview** and has known issues with some components. We don’t recommend using this in production but we would love to hear its impact on loading, rendering and layout performance in your apps.

What Makes a Web App Fast

When we look at what takes up time in a web application, we find it falls into three main categories:

• Initialization: setting up all the class definitions and preparing for launch
• Rendering: creating the HTML markup for all of your components, putting it in the DOM
• Layout: reading CSS information, sizing and positioning all of the components on the page

Measuring the relative impacts of these three areas is important in understanding what to optimize. We’re going to use the SDK’s Theme Viewer example to demonstrate hard data for this post, but the same general outcome follows all of the examples we have been testing.

The Themes Viewer is pretty heavy–it contains over 300 Components, all rendered to the screen on startup. It’s more complex than most startup screens, even in the biggest apps, so we think it’s a good guide to what happens in highly complex UIs.

All of the numbers presented here are measured on Internet Explorer 8 running on commodity, consumer grade hardware. (We test across a range of browsers and examples but this is a representative example). When we run the benchmarks with this setup on the themes viewer, we find that the page takes 4.5 seconds to finish loading. Obviously, we want to make it faster than that and we set ourselves the ambitious goal of halving the load time.

How We Made It Faster

Obviously, layout is enormously expensive when dealing with screens filled with this many components, but rendering and initialization could be improved too. We tackled each in turn, yielding substantial improvements:

Layouts

Layouts were by far the biggest component of application time in 4.0. Layouts have to do a lot–figuring out the sizes and positions of every Component on the page, allowing for margins, padding and borders specified in CSS, then writing all of those values into the DOM. But by altering the order of operations, we’ve been able to substantially improve performance.

Browsers are optimized to do DOM reads and writes in chunks–so interspersing lots of reads and writes can lead to diminished performance through reflows, repaints and cache invalidations. In 4.0 this was well optimized at the individual Component level but was not well optimized when lots of Components were laid out together.

With 4.1 we have developed a system that batches DOM reads and writes into a small number of read/write cycles, which vastly reduces the number of reflows and repaints the browser has to perform. We’ll be following up with a lot more detail on what’s changed with the layout engine in another blog post.

Bulk Rendering

Moving beyond layouts, we next addressed rendering. Rendering 300 Components in one go is quite demanding of the browser, but just like with layouts we were able to batch together the DOM writes required to render everything to the page. Whereas before each Component was rendered separately, in 4.1 the entire Component tree from the Viewport down is rendered in a single write.

This approach yields another big reduction in startup time. Compared with 1100ms in 4.0, 4.1 renders all 300 of the theme viewer Components in **350ms**–that’s a about 1ms per Component, and a 3x speedup over 4.0.7.

Initialization

Finally, we next addressed the lower levels of the framework and optimized a number of functions from the class system through to utilities like MixedCollection. The cumulative effect of these improvements took us from 730ms in 4.0.7 to **300ms** in 4.1–again more than a 2x speed-up.

Results

All of this adds up. While Ext JS 4.0.7 took 4.5 seconds to render this large screen full of Components, the Ext JS 4.1 developer preview does it in just 2.2 seconds. This is a 2x speed improvement on this complex example running on IE8.

The themes example isn’t the only one that got faster, we’re seeing significant performance improvements across all of our examples and in all browsers. We’ve been benchmarking every single example in the SDK, and when we add together the total load times for each we find significant speed improvements once more:

These numbers are preliminary, so you should expect them to fluctuate as we lock down and head towards final release. However, our own testing combined with real world verification from a group of advance testers tells us a that we’re achieving substantial performance gains.

Neptune Preview

While the focus of this release was performance, it’s not the only thing that made it in. At last year’s SenchaCon we demonstrated an exciting new concept theme called Neptune. While it was only a screenshot on a slide, it caused quite a stir and has been one of the most requested features ever since.

Since we first gave a glimpse into Neptune we’ve been iterating like crazy on it. We’ve tested it with the various ways you can put Components together, making sure the colors, margins and borders all look great from netbooks to projector screens. We’re not quite done yet but today we’re excited to be able to release it along with Ext JS 4.1 Developer Preview.

In this preview release we’re targeting modern browsers only–Chrome, Safari and Firefox all look great so for everyone who develops using those browsers (almost everyone we’ve asked falls into this group) you’ll be able to develop using Neptune from day one. As we finalize Neptune based on your feedback we’ll roll out support to older browsers, all the way back to IE6.

Warning–Preview Code

While we’re very happy with the performance improvements we’ve obtained with 4.1, we’d like to be up front about what this release is. We wanted to get 4.1 into your hands so that you can verify the performance improvements in your app and test out the new theme. At the moment we expect that your app will experience visual glitches, odd behavior and even hard JS errors. We strongly recommend against attempting to use this build in production–we’re looking for feedback on performance and Neptune only with this release.

We are expecting some applications to need changes to migrate to 4.1 using this preview–especially if you have written custom layouts and components. This is because we altered some of the low-level architecture of the layout engine, which can have some impact on some more advanced usage of the framework. We will work with you to resolve these issues, and have created a dedicated forum to collect any migration problems you encounter so that we can improve that experience as we approach 4.1 beta.

We hope you like what you see above and that you’ll give Ext JS 4.1 Performance Preview a spin with your own apps. We can’t wait to hear what you think of it and look forward to your responses in the comments!