ExtJS: Performance Best Practices

Think of a tab panel with deferred rendering. You may still need to resolve components that haven't been rendered yet.

OK, thank you.

Generally, it was just thoughts of somehow improve something:) Thank you for your time!

Quote:

---

Originally Posted by Daniil

Yes, it is how the things are now.

But I rather talking about a possible enhancment. Does it really need to instantiate something if it might not be rendered at all?

---

It's been discussed a number of times but it isn't totally trivial to implement as a general feature. Occasionally I implement it myself in my apps. e.g. If I have a main tabpanel in my app then I populate the tabs in their beforeRender methods. Done correctly it can be very effective at improving performance in applications that have a lot of unrendered components.

Quote:

---

Originally Posted by skirtle

It's been discussed a number of times but it isn't totally trivial to implement as a general feature. Occasionally I implement it myself in my apps. e.g. If I have a main tabpanel in my app then I populate the tabs in their beforeRender methods. Done correctly it can be very effective at improving performance in applications that have a lot of unrendered components.

---

This is an interesting approach. How much overhead is it to have unrendered components? Since no dom elements for them have been created, is the overhead mostly the time to instantiate those objects and their memory footprint? AFAIK, most of the performance issues with ExtJS happens during layout and rendering.

Quote:

---

Originally Posted by jchau

Since no dom elements for them have been created, is the overhead mostly the time to instantiate those objects and their memory footprint? AFAIK, most of the performance issues with ExtJS happens during layout and rendering.

---

The time taken to instantiate a component is usually much smaller than the time taken for rendering or layout but if you have huge numbers of unrendered components then it can add up. A tabpanel with many tabs is a good candidate. It should be noted that all I'm proposing is to shuffle time around: cut the time taken for the initial load in favour of slightly slower tab transitions. This is what Daniil seemed to be asking for.

It's just another technique to have in your arsenal. As ever, the only golden rule for optimizing is to take some meaningful measurements before you do anything else.

Quote:

---

It's been discussed a number of times

---

Probably, I missed that. It is a little time ago I started to ponder about performance and, in general, dive deeper into Ext JS:)

@skirtle, thank you! It is nice to know that the idea makes sense at all and even implemented and works.

I will bear in mind that approach to instantiate components in a beforeRender listener. Thank you again.

Carefully use Ext.suspendLayouts/Ext.resumeLayouts. A possible problem is discussed here.
http://www.sencha.com/forum/showthread.php?260320

We have some pretty heavy grids that have extensive templates in the main column to give the user a really nice view of a lot of data in one hit.

So, for performance, what's quicker; a templatecolumn (which would likely require more fields on the grid store to pre-format the data nicely) or a renderer that creates a data object from manipulations on the store on a per row basis and applies an xtemplate on it?

I suppose nested within this question are a few other performance details - like what's quicker, a convert function on a store field or manipulating the store data for each row before applying the template?

Quote:

---

Originally Posted by Jangla

I suppose nested within this question are a few other performance details - like what's quicker, a convert function on a store field or manipulating the store data for each row before applying the template?

---

I prefer a convert function since what's about data should be done in data layer, as much as possible...and the code is cleaner, easy for others to understand and templates are lighter.

Quote:

---

Originally Posted by vadimv

I prefer a convert function since what's about data should be done in data layer, as much as possible...and the code is cleaner, easy for others to understand and templates are lighter.

---

Yea, that's a good point even if performance were the same - keeping all the data trasforms in the model (or store fields) makes for more readable code. My only concern with this is having a store with many more fields if your data needs to be represented many different ways in the grid. But I'm hoping the performance hit for this would be more minimal than having to transform it on the fly each time a row in the grid was rendered.