Closed
Bug 29544
Opened 25 years ago
Closed 25 years ago
Bugzilla query page displays *really* slowly in mozilla
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
People
(Reporter: jst, Assigned: rods)
References
()
Details
(Keywords: perf)
Attachments
(1 file)
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.
Comment 1•25 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•25 years ago
|
||
Comment 3•25 years ago
|
||
The second issue is already noted as bug #29519.
Comment 4•25 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.
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
Adding info from 29519, sorry about the spam...
According to elig@netscape.com (in #29519) it's slow on Macs too.
This was not any slower on mozilla bits today than 4.72. Putting on PDT- radar.
Whiteboard: [PDT-]
Assignee | ||
Comment 10•25 years ago
|
||
My checkk in today should have sped this up quite a bit.
Check it tomorrow.
Reporter | ||
Comment 11•25 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•25 years ago
|
||
See bug 20807 for more info on this problem, although this may not be the only
factor involved here.
Assignee | ||
Comment 13•25 years ago
|
||
Fixed
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 14•25 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 15•25 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•25 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.
Assignee | ||
Comment 17•25 years ago
|
||
fixed
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 18•25 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.
Assignee | ||
Comment 19•25 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•25 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.
Assignee | ||
Comment 21•25 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•25 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!
Assignee | ||
Comment 23•25 years ago
|
||
Sorry to say the GFX work is for post beta1
Comment 24•25 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.
Assignee | ||
Comment 25•25 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•25 years ago
|
||
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
Comment 27•25 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•25 years ago
|
||
If you do decide to reopen, add depends on: bug 18895 (implement GFX scrollbars
for selects)
Comment 29•25 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.
Assignee | ||
Comment 30•25 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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•