Optimization of extjs 4.1-based applications

ArticleDirectory

• Check event listening
• Remove call for dolayout and docomponentlayout
• Reduce container nesting
• Use container to replace the Panel
• Reduce border layout (borderlayout) nesting
• Reduce Dom reading and writing
• Use Ext. suspendlayouts and Ext. resumelayouts to remove additional layout operations.
• Rolling Principle

Address: http://www.sencha.com/blog/optimizing-ext-js-4-1-based-applications/

Although sencha improves the performance of ext JS 4.1, Application Performance Optimization Based on ext JS is still the goal. To optimize the application performance, you need to modifyCode.

This article will introduce how to achieve optimization and a new performance measurement tool for ext JS 4.1-page analyzer. Its main function is to improve application performance. With it, you can determine the measurement indicator soldiers to measure it, so as to identify the bottleneck in the Code, the soldiers take the correct steps to eliminate the bottleneck. PAGE analysis can achieve this. Finally, we will introduce grid optimization, and introduce a new ext JS tool called infinite grid tuner to evaluate grid performance.

Just as we work for ext JS developers, we have noticed several common trends in writing applications.ProgramPerformance adjustment methods should be provided. Although we cannot list every coding technology that drags down an application, the following describes how high developers can improve the performance of the application when using the framework.

General Optimization skills

There are several ways to avoid dragging down the ext js code in the public area.

Check event listening

How to Use event listening in applications is a key to providing performance. For example, if you want to trigger the load event when the store loads data for the first time, the load event will be triggered every time the store loads data. At this time, the first time the store loads data, it triggers the load event and closes it, it will improve the overall performance of the application. The method is to add "Single: True" to the listener ":

Listeners: {<br/> load: onfirstloaddata, <br/> Single: True <br/>}
Another thing that is often ignored is the afterrender event, which is triggered after all DOM elements are rendered. Modifying the elements after rendering will cause backflow (reflows), thus reducing application performance. Instead, use the beforerender event to adjust the element style before rendering so that the element is the correct style during rendering. Sometimes, some code must be rendered and the element size is determined before it can run. At this time, in ext JS 4.1, you can consider using a new event provided by it-boxready, which will be triggered after the component size is determined,

Remove call for dolayout and docomponentlayout

In short, it is to try to remove these expensive calls. In earlier versions of ext JS (before 4.0), dolayout recalculates the layout of the framework when the component or container moves forward. Even in ext JS 4.0, you sometimes need to call it after directly updating the Dom or solving some defects.

In ext JS 4.1, the layout trigger is a little different. Therefore, the Code basically does not need to call dolayout or docomponentlayout. If your application actually needs these calls to solve the error, submit a bug report and fix it.

When the unique non-error occurs, you need to call dolayout or docomponentlayout when the application code directly modifies the Dom. The reason is that the framework does not know such a change, so you need to call them to update the affected layout.

Reduce container nesting

We often see applications with too many nested containers. For example, a container contains only one container, and this container contains multiple components. At this time, you can cancel the outer container and use only one container to do the same work. It is important to remember that initialization, rendering, and layout of each container take time. Therefore, you must exclude unnecessary nested containers so that applications can run faster. Similar code is as follows (the ID attribute is rarely seen here, and it is added here to mark that there are two containers here ):

{<Br/> ID: 'container1', <br/> items: [{<br/> ID: 'container2', <br/> items: [{<br/> ID: 'component3' <br/>}] <br/>}
If possible, the above Code can be reduced to a container:{<Br/> ID: 'container1', <br/> items: [{<br/> ID: 'component3' <br/>}] <br/>}

Use container to replace the Panel

Remember that the ext JS panel is more powerful than the container, but also very expensive. Therefore, it is best to specify "xtype: 'Container'" to avoid applications using the default panel, as shown below:

(Note: A panel contains titles, toolbar, and many other components. Therefore, when instantiating a panel, you need to create instances of many components and perform many layout operations. A container is a simple Div, therefore, the use of containers without any need can greatly improve the performance of applications. This must be noted)

{<Br/> xtype: 'Container', // defaulttype is 'panel '<br/> items: [...] <br/>}

Reduce border layout (borderlayout) nesting

In ext js4.1, border layout Nesting is not required in many cases. Removing nesting reduces the time for initialization, rendering, and layout components. In many cases, versions earlier than extjs need to be nested. For example, there are two or more identical regions in the same region. When there are two north areas in the center area, you must nest the border layout. Now, you can use a border layout to implement two north regions.

In ext js4.1, the area can be dynamically added as needed. Any added area can be displayed on the front end and hidden when not needed. You can also use the weight attribute to define the priority of the region. For example, you can define the priority of the west region before the north region. These changes mean that the nested border buutons is no longer needed, thus improving the rendering speed of the components using the layout.

(Translator's note: This feature is easy to change and now the design layout is much easier than the previous version)

Reduce Dom reading and writing

In ext js4.1, We have minimized the layout's reading and writing to the Dom. Similarly, this is also required in your code. Dom reduces the application speed when reading itself, especially when the DOM write operation is mixed, and this combination will cause reflux. Try to use beforerender to maintain the style, so that you can modify the component during rendering, rather than after rendering. Avoid using setstyle, addcls, removecls, and other statements that directly modify DOM elements. These statements will cause write operations. As a general rule, in order to achieve better performance, when writing to the DOM during maintenance, multiple attempts are made to use batch read and write.

Use Ext. suspendlayouts and Ext. resumelayouts to remove additional layout operations.

Ext js 4.1 provides two new methods: Ext. suspendlayouts and Ext. resumelayouts to Coordinate updates of multiple components and containers. For example, to quickly add two components to two consecutive containers, multiple la S and rendering operations will be executed. If you call the Ext. suspendlayouts method before adding these components, the layout of individual components will not be executed separately. After the addition is complete, call ext. resumelayouts. The framework performs rendering and layout operations only once.

Remember that adding a component will not only trigger the layout operation of the container, but other operations or changes to the component will also trigger the layout operation of the container. It is important to analyze the performance issues in the application to ensure that no redundant layout operations are executed.

{<Br/> Ext. suspendlayouts (); <br/> // batch of updates <br/> Ext. resumelayouts (true); <br/>}

Introduction to ext JS page Analyzer

Ext js 4.1 comes with a new tool that can be used to locate and measure application performance problems. It allows you to quickly detect the impact of code modifications on performance. The page analyzer is linked to the diagnostic tool when loading the ext JS 4.1 page. The page analyzer contains many experimental features. This article describes the most useful layout tabs for optimizing application performance.

You can find this tool in the example folder (examples) of the ext JS 4.1 SDK package:

./Examples/page-analyzer/page-analyzer.html
Copy the entire "Page-analyzer" folder to the application host to be analyzed. Due to browser security problems, the page analyzer must communicate with the Analysis page on the same server, make sure that the page analyzer version matches the ext JS version. If different versions are used, it will strike.

Keep in mind that this tool is the first tool released and is still in development. Therefore, please use the ext JS forum to report the usage of the tool to us.

To use a page analyzer, follow these steps:

1. Open the browser and enter the URL of the analyzer.
2. After opening, enter the test page address in analyzer.
3. The page will be loaded in IFRAME, which is why the analyzer must be on the same server as the application. Shows the analyzer after the page is opened:
4. Click the layout tab to view the layout running status as shown in.
5. You can find multiple layout operations in the same component, and then check your code to see if you can improve performance by reducing layout operations.

Grid Optimization

Ext js grid is a major cause of Web application performance problems, especially when a large amount of data is displayed. When the grid renders a small amount of data, the speed is not a problem. However, when displaying a large amount of data, if you do not pay attention to it, the virtual infinite scrolling will become a performance bottleneck. Infinite scrolling depends on the page cache pages. That is, before you scroll through the grid to display data, you need to save the paging data in the paging scroll object.

When a user scrolls, the cached data becomes visible, and the data that disappears from the top of the page is no longer stored in the Dom. The main way to adjust the Dom is to make the Dom as small as possible and cache data on the client to reduce interaction with the server.

Rolling Principle

When the configuration item buffered of the store is true, a pagingscroller object is instantiated to monitor the scrolling of the view (data view inherent in the grid, at the same time, it is necessary to provide real-time data for the view's upcoming traversal operations and cache paging data.

This section describes how to obtain data from a view chart during scrolling. Pageingscroller maintains a leading buffer zone in the forward direction, while a small backward cache zone in the back direction.

Pagingscroller requires store to ensure that both the backward and forward buffers are in the buffer. Therefore, you need to calculate the pages that are needed to ensure that they are cached, store only needs to request pages that are not cached through Ajax.

When the view scroll down, the border of the rendered table will enter the view. When the distance from the margin numfromedge row is reached, store will load the data to continue, at the same time, the vertical coordinates are synchronized to ensure that the visible lines are in the same position. When the required data is cached on the page, this operation is implemented instantly and virtually. If the scroll bar is dragged beyond the cache page, the yieldajax request is sent, and the request is masked until the data is returned.

If the rolling increment is within a reasonable speed range and the leading boundary of the request area enters another page that is not cached, Ajax is called to request this page. In most cases, if the leading buffer area is large enough, it renders the table before reaching the cache row.

By default, the page cache only caches the last five pages used. This is added based on browsing conditions, so that more data is cached on the client, thus reducing Ajax requests. The purgepagecount configuration item of store can control this behavior.

If the data is not too large, such as 50000 rows, You Can cache the entire data to the client. Set the purgepagecount of the store configuration item to 0, and the page will not be discarded after the page is cached.

How to design a large table depends on how rendering and browsing speed. The larger the table, the larger the scroll range between the view and the boundary and between the prefetch buffer and the updated data. However, the more data obtained from the prefetch buffer, the longer the re-rendering time. This requires a balance between visual data and re-rendering. If the target application is a quick browser, you can choose to display more rows and data. If it is a slow browser, you can use a table with a small number of rows displayed, so that it can quickly reach the visible boundary and adapt to regular and frequent refreshes.

To help you debug the grid, there is an example named "infinite grid tuner" under the examples directory in the ext JS 4.1 package, which contains a 50 thousand data dataset, you can set different methods to load data to the store through preprocessing buffering. For example, you can simulate Ajax latency, modify the number of rows of prefetch data, and adjust the table size. You can modify different parameters displayed on the left side to learn how to set them so that your applications can perform better in the browser.

Using infinite grid tuner, you can adjust the purgepagecount settings of the store. This setting will delete a large amount of data from the page cache after rendering. If it is set to 0, it will save all the data in the cache, which means that if you scroll the grid, you do not need to load the data from the server.

Using infinite grid tuner requires two concepts: visual data in the grid can be seen as a sliding window. Similarly, the page cache can be viewed as all the data in the grid-related sliding window. You can use tuner to change the size of the two. You can also add rules for them to determine the location of the user's number of rolling lines between the visible boundary and the data retrieved from the grid visible part and the page cache.

Additional resources

The following resources are also useful for Application Performance Tuning:

• View A 50-minute webinar video version of this blog
• Suggestions from other ext JS users in the sencha Ext: Open Discussion Forum performance best practices thread
• Tips for optimizing Internet Explorer 8 and higher
• Information about dynatrace performance management technology for Internet Explorer and Firefox
• Chrome speed tracer website and tutorial
• Firebug profiler tutorial

Author:Don Griffin
Don Griffin is a member of the ext JS core team. he was an ext JS user for 2 years before joining sencha and has over 20 years of software engineering experience on a broad range of platforms. his experience designing web application front-ends and back-ends, native GUI applications, network protocols and device drivers. don's passion is to build world class products that people love to use.