Performance guide

[latterd]

Hi all,

I am new to ExtJs and I am wondering if there are any performance guides
Or best practices guides that anyone can point me to?

I am looking for examples of the proposed architecture for an
ExtJs app.

Background:
At the moment I am building an app where I have number of
tabs, each tab contains a grid panel. At the moment I have a js file
for each grid, for example i have a users.js file that defines
the grid for the "users" tab, and so on. I am wondering if it
would be best to make my own type of grid and just change columns
And store for each grid on the fly?

If anyone has any pointers on the above or links to any docs
I would be very grateful.

Many thanks.

[skirtle]

Architecture:

http://docs.sencha.com/ext-js/4-0/#!...n_architecture
http://docs.sencha.com/ext-js/4-0/#!/guide/mvc_pt1

Though I didn't entirely follow your example, if you have multiple grids with similar configurations then it would make sense to extract a subclass of grid that you can use in those cases. Whether this is appropriate in your circumstances is a judgement call you'll have to make. You should consider whether the similarities at this stage are likely to continue as development of your app progresses.

As for performance, here are a few common ones:

• Don't over nest. Most newbies nest panels several layers deep when a single panel will suffice.
• Don't use a panel when a container will do. Likewise for other classes.
• Don't gratuitously use a panel when some simple HTML or an Ext.Template will suffice.
• Production builds should use concatenated, minified versions of all the source to improve load time.
• Production builds should generally use a custom ExtJS build to reduce the file size.
• Be wary of components or stores that don't get destroyed when they are discarded, memory can quickly leak.

[stevil]

Architecture:

http://docs.sencha.com/ext-js/4-0/#!...n_architecture
http://docs.sencha.com/ext-js/4-0/#!/guide/mvc_pt1

Though I didn't entirely follow your example, if you have multiple grids with similar configurations then it would make sense to extract a subclass of grid that you can use in those cases. Whether this is appropriate in your circumstances is a judgement call you'll have to make. You should consider whether the similarities at this stage are likely to continue as development of your app progresses.

As for performance, here are a few common ones:

• Don't over nest. Most newbies nest panels several layers deep when a single panel will suffice.
• Don't use a panel when a container will do. Likewise for other classes.
• Don't gratuitously use a panel when some simple HTML or an Ext.Template will suffice.
• Production builds should use concatenated, minified versions of all the source to improve load time.
• Production builds should generally use a custom ExtJS build to reduce the file size.
• Be wary of components or stores that don't get destroyed when they are discarded, memory can quickly leak.

I'd add the judicious use of Yahoo!'s ySlow ratings to the list.

[latterd]

Hi,

Thanks skirtle and stevil for your replies.

skirtle,
I understand your points regarding architecture - I was trying to keep post terse, I guess it was too terse
Thanks for the points you mentioned.

There are just 2 of the points I have questions if you dont mind:

Production builds should generally use a custom ExtJS build to reduce the file size

Do you make a custom build via the "builder" provided in the ExtJs package?

Be wary of components or stores that don't get destroyed when they are discarded, memory can quickly leak.

How would I make sure they are destroyed? Is it just a case of using some debugging to check for a memory leak or is there somthing at the code level I can do to mitigate this? Also, when you say "..discarded.." is this when, for example, I delete a store in code or equally when I traverse to a different page?

stevil,
Cheers for the tip,

Many Thanks.

[skirtle]

Do you make a custom build via the "builder" provided in the ExtJs package?

Yes. This can help load times but probably won't improve UI snapiness. I wouldn't do this until your app has matured a bit, working with a cut down build gets really annoying when you need to use the bits you've cut out.

How would I make sure they are destroyed?

When a component is created it is registered with the component manager. The component's destroy() method will, among many other things, unregister it with the manager. This is important because the JS garbage collector can't reclaim a component if there's still a reference to it from the manager.

You can see all the components in your app using Ext.ComponentManager.all.

ExtJS does what it can to destroy components for you. When you destroy a container it will destroy all of its children for you. When you remove a component from a container it will, by default, be destroyed. When a window or tab is closed the default is to destroy it.

However, there are still problem cases. Consider a grid with a context-menu for the rows.

First imagine that we listen to the contextmenu (right-click) event and create a new menu each time it fires. Everything looks fine. But when the menu is dismissed it is hidden, not destroyed. Gradually the number of menus will creep up and up. In this case you can even see them in the DOM, hidden but very much still there.

One attempt at fixing this is to reuse the same menu each time. Somewhere during construction the grid could do something like this:

this.contextMenu = Ext.create('Ext.menu.Menu', {...});

Then, in the contextmenu event listener:

this.contextMenu.showAt(event.getXY());

This stops the number of menus creeping up each time we right-click a grid row but it doesn't necessarily solve the problem completely. If the grid is destroyed (maybe it's in a tab that gets closed) there's still nothing to destroy the menu. The grid will need some custom logic adding to destroy the menu when it is destroyed.

Going back to the original approach of creating a new menu each time, this can be made to work by destroying the menu in a hide event listener.

This just scratches the surface of some of the memory leaks that can occur. ExtJS does what it can to help you but it can take some time to learn exactly what's tidied up by magic and what you have to do manually. One thing to note is that for many apps these leaks really don't matter. It usually only becomes a problem if your users are using the app for long periods of time. Even then they can reset the page by reopening their browser, so you've got to evaluate whether it's worth the development time to fix them.

[stevil]

@skirtle,

Don't you know that Browser and Framework leaks are so 2010?

[skirtle]

Don't you know that Browser and Framework leaks are so 2010?

I hadn't heard. I am so legacy.

It seems 2011 is all about the cloud. I guess that protects you against memory leaks. It's difficult for memory leaks to add up if an app is painfully slow then falls over after half an hour...

[stevil]

I hadn't heard. I am so legacy.

It seems 2011 is all about the cloud. I guess that protects you against memory leaks. It's difficult for memory leaks to add up if an app is painfully slow then falls over after half an hour...

I've always been convinced that Microsoft is in league with memory manufacturers, because it seems that the only cure for memory leaks is an infinite supply of it!