Extjs 4.1 performance Preview

Original article: http://www.sencha.com/blog/ext-js-4-1-developer-preview/

I'm glad that a preview version of extjs 4.1 for performance improvement is released today. Over the past few months, we have been striving to improve loading time, rendering, and overall layout performance, and have been using our own examples and your applications.ProgramCross-browser Benchmark Testing and performance optimization were performed, and some significant improvements were made.

Today, we will open the current generation package so that your application can feel the speed improvement. We hope you can use this version to test your application, but note that this version is only a preliminary version. This is only a pre-tested performance preview version and some components have problems. We do not recommend using it in a production environment, but we are happy to hear responses to loading, rendering, and layout performance in applications.

Download here

How to make Web applications faster

We noticed that the processing time in Web applications mainly includes the following three categories:

■ Initialization: Initialize all class definitions and prepare for running.

■ Rendering: Creates tags for all components and binds them to the Dom.

■ Layout: Read CSS information on the page and adjust the size and position of the component.

Understanding the interaction between these three aspects is very important for optimization. We will use the theme viewer example in the SDK as the demo data in this article. After Continuous testing, the results of other examples are the same.

Topic viewer is rather bulky. It contains more than 300 components and is rendered to the page at startup. It is more complex than most startup pages, even the largest application, so we think it corresponds to a highly complex user interface is a pretty good example.

The data shown here is tested on IE8 running on the hardware of the consumption grade (we think this is representative in the browsers and examples we have tested ). When initializing the Benchmark Test of the topic viewer, we found that loading of the page would take 4.5 seconds. Obviously, we need to achieve the ambitious goal of reducing loading time by half.

How to make it faster

Obviously, layout processing is quite expensive for pages filled with components, but it can also be improved through rendering and initialization. We will handle the issue in sequence and make substantial improvements:

Layout

In 4.0, the layout is the most time-consuming component so far. La s do a lot of work, such as finding the size and position of each component on the page, applying margin, fill, or border styles, and writing them into the Dom. By changing the operation sequence, we can greatly improve performance.

Optimize the operations for reading and writing data blocks from the browser Dom. Because too many read/write operations are performed through reflows, repainting, and invalid caches, the performance will be reduced. When many components are deployed together, 4.0 is only optimized for individual components, and the effect is not good.

In June 4.1, we developed a mechanism for batch processing Dom read/write in the read/write cycle, which greatly reduces browser backtracking (reflows) and repainting operations. This is a little dramatic, with more than 20 reflows in 4.0 ).

Batch Rendering

Over the layout, we will discuss Rendering now. Rendering 300 components at a time is quite laborious for browsers, but like layout, you can write pages together by writing DOM in batches. Since each component is rendered separately before, in 4.1, the entire component tree is rendered to the page at a time under viewport.

This method also greatly reduces the startup time. In 4.0, it takes 300 microseconds to render the 1100 components of the topic viewer. In 4.1, it only takes 350 microseconds to render a component in almost 1 microsecond, which is three times the speed of 4.0.7.

Initialization

Finally, we will discuss the underlying framework and how to optimize the functions of class systems through functions such as mixedcollection. The cumulative effect of these improvement measures is increased from 730 microseconds of 4.0.7 to 4.1 microseconds of 300, with a speed greater than twice.

Result

All of these improvements. In 4.0.7, it takes 4.5 seconds to render a large page filled with components, while in 4.1, it only takes 2.2 seconds. Run this complex example on IE8, with a speed increase of 2 times.

Theme examples are not the only example that gets about faster. All of our examples have significant performance improvements in all browsers. We conducted a benchmark test for every example in the SDK. We compared the total loading time of the sample and found that the speed was significantly improved:

These numbers are only preliminary figures, so they may fluctuate with your expectation for the final version. However, through our tests and the actual verification by a group of priority testers, we have achieved a significant performance improvement.

Neptune Preview

Although this version focuses on performance, it is not the only thing. Last year's senchacon showed us an exciting theme called Neptune. Although it was only one on a slide, it caused a lot of sensation. Since then, it has become one of the necessary functions.

Since the beginning of Neptune's glance, it has been pursued in crazy ways. After testing, you can put components together in various ways to ensure that all colors, margins, and borders look great from the netbook projection to the screen. Although we have not completed it yet, we are very happy to integrate it with extjs 4 today. 1. The Developer Preview is released together.

In the current preview version, we target modern browsers like chrome, Safari, and Firefox. Developers basically use these browsers (we have consulted almost everyone in this group ), in this way, you can use Neptune from the very beginning. Based on your feedback on Neptune, we will finally determine the support for older browsers until ie6.

Warning PreviewCode

Although we are very happy that 4.1 has achieved performance improvement, we still need to explain the reason for the release of this version. We hope to send 4.1 to you as soon as possible to verify the performance improvement of your application and test new theme. Currently, we expect that your application may have problems such as Visual flaws, weird behavior, and even JS errors. Therefore, we strongly recommend that you do not try to use this version as a production version. This version is only used to collect performance and Neptune feedback.

We estimate that some applications need to be migrated to 4.1 through some modifications in this preview version, especially those with custom la S and components. This is because we modified the underlying architecture of the layout engine, which has a certain impact on the advanced applications of the framework. We will try to solve these problems for you. We have established a special forum to collect any migration problems encountered during your migration, so as to improve the experience of the 4.1 beta version.

We hope you like what you see above and transfer your application to extjs 4.1 performance preview. We can't wait to see your response in the comments.

Author:Ed Spencer
Ed Spencer leads the development of ext JS and sencha touch. an expert with ext JS and Javascript in general and with several years experience with traditional server side frameworks, He has broad experience in API design and delivery. his passion is in crafting beautiful code that supports the World-class sencha product line.