Bugzilla query page displays *really* slowly in mozilla




19 years ago
18 years ago


(Reporter: jst, Assigned: rods)




Firefox Tracking Flags

(Not tracked)




(1 attachment)



19 years ago
Displaying the bugzilla querypage in mozilla is *really* slow (20+ seconds on a
400MHz PII, debug build) in todays bulild on linux (I think it's been like this
for the past week or so). Also, selecting a different program (the "Program:"
select box) is really slow too.

Comment 1

19 years ago
I get 30+ sec with 500MHz PIII to remote x-server (debug build). Nightly
is a bit faster (14 sec).

This is much faster (1sec with nightly) when you strip javascript
off from that page. I attach a tripped version of query page.

Comment 2

19 years ago
Created attachment 5866 [details]
stripped version of query page

Comment 3

19 years ago
The second issue is already noted as bug #29519.

Comment 4

19 years ago
I've been seeing this for about a week.  It's a lot better in a release build,
but I still wait a few seconds while all the selects render.

Comment 5

19 years ago
I timed this on a release build from today on WinNT (400MHz PII, MOZ_PERF turned
off) and it takes about 6s to display and selecting different programs takes
about 5s.

I'll mark #29519 as a dup of this (since this has more info).
OS: Linux → All
Hardware: PC → All

Comment 6

19 years ago
*** Bug 29519 has been marked as a duplicate of this bug. ***

Comment 7

19 years ago
Reassigning to Rod.
Assignee: karnaze → rods

Comment 8

19 years ago
Adding info from 29519, sorry about the spam...

According to elig@netscape.com (in #29519) it's slow on Macs too.
Keywords: beta1, dogfood

Comment 9

19 years ago
This was not any slower on mozilla bits today than 4.72.  Putting on PDT- radar.
Whiteboard: [PDT-]

Comment 10

19 years ago
My checkk in today should have sped this up quite a bit.

Check it tomorrow.

Comment 11

19 years ago
Yes, i't a *lot* faster today, but it's still not as fast as 4.x, especially
not when selecting different programs.

However it is definitely usable now, thanks rods!

Comment 12

19 years ago
See bug 20807 for more info on this problem, although this may not be the only
factor involved here.

Comment 13

19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 14

19 years ago
Reopening.  In my linux debug build this morning, the query page sits for 5-7
seconds showing grey areas everywhere select elements will be.  I don't think
that's much faster than it was yesterday, and it's certainly a lot slower than
4.x.  I realize that debug builds are slower than optimized ones, but I also
have a fairly fast machine.
Resolution: FIXED → ---

Comment 15

19 years ago
Is the fact that GFX scrollbars are not used for listboxes somehow related to

this speed problem? On linux, while waiting for the page to load, I see my GTK

theme scroll bars, not where the list boxes will be, but scattered up at the top

of the page.  I do not see any of these gray areas.

Comment 16

19 years ago
Ditto, selecting a program within the Bugzilla quick page on a 266 Mhz G3 Mac
using the 3.3.00 AM build requires 7 seconds of redraw.

Comment 17

19 years ago
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 18

19 years ago
Are you sure this is fixed? Linux build 2000-3-7-9 taking 10 to 25 seconds to
load the page vs. ~1 sec. on netscape 4.72.

Comment 19

19 years ago
Did you pull the changes I checked in today?

If so, and it is still this slow, then reopen the bug. Thanks.

Comment 20

19 years ago
It's definitely faster now ... the grey boxes are there for about 4 seconds on
my debug build.  This is still a lot slower than 4.x, but much better than it was.

Comment 21

19 years ago
I anticipate another speed up especially for Linux when I turn on Gfx ListBoxes. 
One reason is the native scrollbars will go away and this only slowes things 
down and looks bad. I have them working 100% in my tree, and they look good. Now 
just to get the dropdown using the GfxList.

Comment 22

19 years ago
I take that back, it is definitely faster overall.  There were occasional 20
sec. hangs this morning, probably caused by server problems.  But seems to be
under 5 sec. on average now.  Great work! Here's hoping that you get your GFX
code checked in for beta!

Comment 23

19 years ago
Sorry to say the GFX work is for post beta1

Comment 24

19 years ago
rods, is GFX part of this bug?  If so, and GFX is not going to be fixed until
post-beta, then we need to re-open this bug.  If it is not part of the bug, then
we need to open a new one specifically for GFX, if one doesn't already exist.

Comment 25

19 years ago
I think of it this way, if the current performance is still not good enough, 
reopen this bug. But I would suggest that the PDT-, beta1 & dogfood are removed 
because I think the current faster performance is good enough for dogfood.

Then once I have in the Gfx listboxes in we can check the speed and see if it 
is good enough. Then determine at that point if anything more can/could be done 
for the list (and combobox) to speed it up.

Comment 26

19 years ago
Well *dang* if it don't look good...
- Linux6 2000-03-07-09 Commercial build
- MacOS9 2000-03-07-08 Commercial build
- Win98 2000-03-07-09 Commercial build

Comment 27

19 years ago
Rods changes makes this MUCH better, and completely fixes combo-box problems
(see bug #30002). But query page still is slow, and somehow it takes 5sec to
load it on debug build, and 20sec!! on opt-build. In opt-build there is much
flickering on three selectboxes (Version, Component, Tarrget milestone).
Also selecting "Program" takes about 7sec with much flicker.
(Tested with 500MHz PIII to remote x-server) 

I think those both is becouse javascript is changing select's contents on onLoad
and onSelect -events.

So i would say that this should reopen, and clear beta1 and dogfood keywords.

Comment 28

19 years ago
If you do decide to reopen, add depends on: bug 18895 (implement GFX scrollbars
for selects)

Comment 29

19 years ago
This is still a problem, partly because of all the cruft that gets drawn as the
combo boxes are being recomputed.  To see an example of this, go to the query
page, change the Product to MailNews, and watch the window while it redraws and
redraws and redraws many times.  The whole process takes about 3 sec on my
PII/450, and the time taken might even be livable, but all the redrawing during
that time looks awful.

Can't combo box reflow wait 'til it's done before repainting?

Removing previous PDT status, and dogfood keyword; adding beta3 and perf keywords.
Keywords: dogfood → nsbeta3, perf
Resolution: FIXED → ---
Whiteboard: [PDT-]

Comment 30

19 years ago
Setting this backed to fixed, it is more of a problem with batching reflows 
instead of having them reflowing everytime an option is added. This very problem 
is covered by bug 27233, which I have been talking to nisheeth about.
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 31

19 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 32

18 years ago
Build: 2000092711 MN6
Platform: WinNT
You need to log in before you can comment on or make changes to this bug.