Closed Bug 29544 Opened 25 years ago Closed 24 years ago

Bugzilla query page displays *really* slowly in mozilla

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jst, Assigned: rods)

References

(
URL
)

Details

(Keywords: perf)

Attachments

(1 file)

stripped version of query page
22.59 KB, text/html
Details 
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.
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.
The second issue is already noted as bug #29519.

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.

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
*** Bug 29519 has been marked as a duplicate of this bug. ***
Reassigning to Rod.
Assignee: karnaze → rods
Adding info from 29519, sorry about the spam...

According to elig@netscape.com (in #29519) it's slow on Macs too.
Keywords: beta1, dogfood
This was not any slower on mozilla bits today than 4.72.  Putting on PDT- radar.
Whiteboard: [PDT-]
My checkk in today should have sped this up quite a bit.

Check it tomorrow.
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!
See bug 20807 for more info on this problem, although this may not be the only
factor involved here.

Fixed
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.


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.

fixed
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.
Did you pull the changes I checked in today?

If so, and it is still this slow, then reopen the bug. Thanks.
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.

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.
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!
Sorry to say the GFX work is for post beta1
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.
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.
Well *dang* if it don't look good...
Marking VERIFIED FIXED on:
- Linux6 2000-03-07-09 Commercial build
- MacOS9 2000-03-07-08 Commercial build
- Win98 2000-03-07-09 Commercial build
Status: RESOLVED → VERIFIED
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.
If you do decide to reopen, add depends on: bug 18895 (implement GFX scrollbars
for selects)
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.
Status: VERIFIED → REOPENED
Keywords: dogfood → nsbeta3, perf
Resolution: FIXED → ---
Whiteboard: [PDT-]
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Updating QA contact.
QA Contact: ckritzer → bsharma
Build: 2000092711 MN6
Platform: WinNT
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: