PDA

View Full Version : Grid performance profile using Firebug



Animal
26 Feb 2007, 9:13 AM
I'm not moaning about performance because I know the grid does a hell of a lot of processing on the data. I'm just curious.

My grid takes a while to appear. I had put it down to network latency, but the data in my example is in fact very small - 6 database rows, and comes back very smartly from localhost.

When I profiled the time from setting the query off to the grid appearing I got the following results:

http://i131.photobucket.com/albums/p286/TimeTrialAnimal/gridprofile.jpg

You can see that the majority of processing takes place in CSS.updateRule. More than 5 seconds over only 78 calls.

jack.slocum
27 Feb 2007, 7:49 AM
78 calls :shock: auto size columns with a lot of columns?

Animal
27 Feb 2007, 8:45 AM
There are 6 rows of 13 columns.

I don't understand why it calls updateRule 78 times. As it goes through calculating column widths, it should just store the maximum width for each column until its been through "maxRowsToMeasure" rows (or the total rows).

After it's done this, it should call updateRule once for each column. That should be 13 calls.

Animal
27 Feb 2007, 8:50 AM
OK, forceMinSize is being passed as true by GridView.autoSizeColumns, so GridView.autoSizeColumn is updating the data column width (and possibly the header column width if "autoSizeHeaders" is set) every time.

Animal
27 Feb 2007, 9:10 AM
I'e been looking at the code in GridView with a view to refactoring it a little.

The thing is, a lot of the methods have side effects which other methods rely on, so I don't think I can unpick it myself.

I'm sure it can be tuned a bit though!

jack.slocum
27 Feb 2007, 9:49 AM
Yes it can. Right now the goal is to get everything working. Then documentation and optimizing. :)

Animal
27 Feb 2007, 10:45 AM
Yes it can. Right now the goal is to get everything working. Then documentation and optimizing. :)

Absolutely, I understand that this is Alpha test... just my ?0.02 on a starting point. :) I know you keep things in mind very well!

jack.slocum
28 Feb 2007, 9:12 AM
Performance has been improved when in a layout in the next release. It should be noticable.

jeffiel
28 Mar 2007, 3:52 PM
Hi All,

My cpu is fairly pegged, so I'm doing some profiling. Page has a four grids, some hidden in inactive tabs, some visible. A few border layouts, etc.

To my surprise, the culprit is element.getStyle, which is called a few thousand times a second, even when the browser is not in use. I have firebug open in a separate window, I hit profile wait a couple seconds, stop the profiling. Never touched the application window, and I get this:


Function calls Percent Own Time Time Avg Min Max
getStyle 9024 57.91% 875.872ms 875.872ms 0.097ms 0.066ms 3.437ms


Here's the whole profile:

https://ninja.9star.com/public/ygrid/profile1.gif

Jack or anybody on the support team, I'd definitely appreciate some pointers here. My code doesn't have any recurring methods that would trigger constant inspection of the ui.

Thanks!

jack.slocum
28 Mar 2007, 4:00 PM
There should be no calculations taking place is nothing is happening. Can you give any more details on your set up?

jeffiel
28 Mar 2007, 4:06 PM
There should be no calculations taking place is nothing is happening. Can you give any more details on your set up?

Hi Jack, I just updated my original post with the whole process list.

I've got a few libraries loaded, in this order:

prototype
scriptaculous
sarissa
jquery
ext

I'm working now on purging sarissa from the app, and I know you recommend that ext come before prototype, so I'm working on that too (making sure it won't break anything).

FF 1.5 / Mac 10.4

What other information would be useful?

jack.slocum
28 Mar 2007, 4:39 PM
It looks like you have some kind of infinite looping. It's hard to guess what is causing it.

jeffiel
28 Mar 2007, 5:04 PM
I'm rooting out the other libraries, and I'll let you know how it goes. Thanks for letting me now that ideally, there would be no activity when idle.

jeffiel
31 Mar 2007, 4:28 PM
I've narrowed it down to the autoExpandColumn in the grids... when enabled, layout() on the GridView() runs continuously. Here's the offending code:

GridView.js line 1355 (rev4)


if(!gv.userResized && expandCol && gv.ds.getCount() > 0 && w > (tw = cm.getTotalWidth(false))){
// high speed resize without full column calculation
var ci = cm.getIndexById(expandCol);
var cw = ((w-tw)+cm.getColumnWidth(ci)-2)-/*scrollbar*/(w <= s.dom.offsetWidth ? 0 : 18);
cm.setColumnWidth(ci, cw, true);
gv.css.updateRule(gv.colSelector+expandCol, "width", (cw - gv.borderWidth) + "px");
gv.css.updateRule(gv.hdSelector+expandCol, "width", (cw - gv.borderWidth) + "px");
gv.updateSplitters();
gv.layout();
}


Note that if expandCol, then that last block would call gv.layout again. Loop.

jeffiel
2 Apr 2007, 10:56 PM
Hi Jack,

Can you let us know when this bug is verified and/or addressed. It seems to be a prett serious issue.

Thanks!

-jeff

snid
27 Apr 2007, 10:30 AM
Can you let us know when this bug is verified and/or addressed. It seems to be a prett serious issue.

I just ran into the same problem...

I would change the data for the grid and call dataStore.reload() which would peg the CPU. Resizing the grid would make it return to normal.

Removing the "autoExpandColumn" from my grid made the CPU not get pegged.