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.
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.
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.
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?
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.
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.
Originally Posted by Daniil
Reply With Quote
