Major page render time regression in 3.0-dev for many-bugtask bugs

[Max Bowsher]

Compare the page render time (load times are roughly similar) for a bug with many bugtasks - e.g. bug 427356 - on lpnet vs. edge.

Major regression.

Also, firefox goes unresponsive and chewing 100% CPU for a long time whilst loading the edge page.

[Deryck Hodge (deryck)]

Gavin will take a look today to determine the cause and impact -- i.e. if we have a 3.0 UI issue at work here, or a variety of problems.

[Eleanor Berger (intellectronica)]

It seems unlikely that this is a 3.0 UI issue, since this page has not yet been converted. If the performance difference is consistent, it could be any landing in the last two months. The most significant change that may involve more queries is the addition of more AJAX controls, some of them require extra data for the initialization.

[Gavin Panella (allenap)]

Confirmed in FF 3.5 and Chromium, both on Ubuntu.

[Gavin Panella (allenap)]

The problem seems to be in setup_bugtask_row(). I haven't isolated what exactly, but disabling that function makes everything work fine again.

[Gavin Panella (allenap)]

I think I've narrowed it down to Y.lp.picker.addPickerPatcher().

[Gavin Panella (allenap)]

The following diff prevents the page from stalling towards the end of
the load/render process. There's a lot more code in the function
that's being returned from, but the line that's commented out below is
able to cause a stall all on its own (at least, for me, on FF 3.5,
Ubuntu 9.04).

Of course, we can't land this. It's only an avenue for exploration
tomorrow.

--- lib/canonical/launchpad/javascript/lp/picker.js 2009-08-26 15:51:46 +0000
+++ lib/canonical/launchpad/javascript/lp/picker.js 2009-09-16 16:59:27 +0000
@@ -144,7 +144,8 @@
         });
     };

- var picker = Y.lp.picker.create(vocabulary, save, config);
+ //var picker = Y.lp.picker.create(vocabulary, save, config);
+ return;
     picker._resource_uri = resource_uri;
     var extra_buttons = Y.Node.create(
         '<div style="text-align: center; height: 3em; ' +

[Gavin Panella (allenap)]

Have done some more debugging, and it seems that there isn't a single
culprit. The picker code (as mentioned in the last comment) is
certainly partly to blame, but Firefox has stopped the script in
importance_choice_edit.render() too, in <widget>.syncUI(). I think
that the overhead of rendering so many widgets in the page - all of
them in Y.on('load') - means that the browser stalls for a long time.

Additionally, as these widgets are being rendered, FF needs to do
layout on the bugtask table again. For me, it tries to do this as the
script runs, rather than waiting until the end; this is probably quite
a big overhead. I will investigate to see if there are any ways to
prevent layout while the onload code runs.

Also, using a shared "Y" object doesn't seem to make a big difference
so far.

[Gavin Panella (allenap)]

Actually, the bit about doing layout while the script runs appears to
not be the case.

[Diogo Matsubara (matsubara)]

Fixed in devel r9550 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/9550>