View Full Version : Performance A2Rev5: Tab Switching with a tab being a Grid

26 Feb 2007, 2:54 PM
Has anyone else run into a performance issue with tab switching. In my program I have a search tab that retrieves around 40 rows. I've noticed a performance issue with rendering between tabs which causes a 1-2 second delay. I know this is connected to the grid rendering too much data because if I limit the search scope to return fewer items the performance picks up. I was wondering if there were solutions to this issue besides limiting the scope of the data returned. Any advice would be welcome. Thanks...

27 Feb 2007, 1:38 AM
Just for info, analyze the tab switching processing using Firebug's profiler and post the results as a screenshot. Let's see what bit of code is taking the time.

27 Feb 2007, 4:43 AM
I had the same problem, see profile:



27 Feb 2007, 8:38 AM
What is that profile for - just the tab switch? Seems like it has a lot of extra calls for other stuff.

If you can limit it, it will help more. Also, sorting by "own time" is also helpful.

27 Feb 2007, 10:51 AM
Here's a snap shot of my code switching between the two tabs.


28 Feb 2007, 9:14 AM
Where are the CustomEvent calls coming from?

Anyway, is this in a layout? If it is, you will be seeing a nice performance boost switching tabs in the next rev.

28 Feb 2007, 10:41 AM
I'm not actually sure where the CustomEvent calls are coming from. This was my first time to actually use the profile, so I'm not quite sure what's causing them. Yes, this is inside of a layout, so if there's a performance boost coming I'm looking forward to it. Food for thought: Although, I am assuming they are using YUI to create their mailer. I did test tab switching within the YAHOO's beta mailer and it's pretty fast within their layout.

28 Feb 2007, 10:45 AM
Yahoo Mail doesn't use YUI components. I'm not sure if they ever worked in YUI utilities. I haven't used it in a while so that may have changed.

28 Feb 2007, 1:28 PM
They have two different mailers. One is the old basic mailer that is non-AJAX'd. The new one was created by the developers from Oddpost.com. The new one looks more like the Outlook mailer. They even have it hooked up to the Yahoo Messenger Service. By the way, posted below is the same test with Alpha 2 Rev 6 (I wasn't sure if you meant the upgrade would be in rev6)


28 Feb 2007, 2:00 PM
We are getting somewhere I guess. beginMeasure/endMeasure should not be running that long. I will look at the code.

28 Feb 2007, 2:10 PM
I was looking at that, and I'm not sure if this has an effect on the redraw, but I'm guessing it would. I'm running the browser in a window that's set at 1900 x 1200 on a 22'' monitor. Unfortunately, that's most likely the environment that our users will be using. If this doesn't have an adverse effect on it, please ignore this posting.

8 Mar 2007, 7:52 AM
I wrapped timers around line 3 below (el.offsetWidth, el.offsetHeight) and it is VERY slow in some cases. Especially when switching between heavily gridded tabs. The offsetWidth calculation seems to slow down on heavy nodes.

I'm not sure anything can be done about this since offsetWidth is pretty much required for calculating widths and it's a browser thing (excepting the getCalculatedWidth() that isn't 100% accurate).

Note that I'm not yet using the 1.0 alpha - I just used the alpha code to show where the bottleneck is.

beginMeasure : function(){
var el = this.dom;
if(el.offsetWidth || el.offsetHeight){ <--- THIS IS SLOW
return this; // offsets work already
var changed = [];
var p = this.dom, b = document.body; // start with this element
while((!el.offsetWidth && !el.offsetHeight) && p && p.tagName && p != b){
if(D.getStyle(p, "display") == "none"){
changed.push({el: p, visibility: D.getStyle(p, "visibility")});
p.style.visibility = "hidden";
p.style.display = "block";
p = p.parentNode;
this._measureChanged = changed;
return this;


Jack, please come through on this! ;-)