Closed
Bug 52149
Opened 24 years ago
Closed 23 years ago
Scrolling bookmarks tree is absymally slow
Categories
(Core :: XUL, defect, P2)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla0.9.7
People
(Reporter: jesup, Assigned: bugzilla)
References
Details
(Keywords: perf, Whiteboard: [nav+perf][ben-m5])
Attachments
(1 file)
(deleted),
text/html
|
Details |
FreeBSD 2000091008 (pull/build)
Scrolling bookmarks (Manage bookmarks and sidebar) after importing a 350K
bookmarks file (with many folders, all close) is VERY VERY slow. 2-6 seconds to
respond to a click above or below the slider. I've seen (and reported) similar
problems with history lists, etc in the past. I suspect it's all due to issues
with scrolling trees.
Related issue: it also take 3-8 seconds to open the Bookmarks menu.
I'll attach the bookmarks file.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Although I have a similar bookmarks file, and would love to see this fixed soon,
this is an edge case, and will probably affect less than 1% of users, so it is
not a good place to spend our time. This will probably impove due to general
tree speedups.
->future, helpwanted.
Keywords: helpwanted
Target Milestone: --- → Future
Reporter | ||
Comment 3•24 years ago
|
||
Note: with a 26K (~185 URL) bookmarks file (which is smaller than most
peoples!), scrolling in Manage Bookmarks takes about 1-2 seconds per click.
Faster, but still very slow. (PIII 450 w/ 256MB). Using the slider is painful
due to the jerky updates.
Also, while bookmarks may not _too_ often get that large (I'd think more than
1%), History lists can be VERY large.
Comment 4•24 years ago
|
||
Your metrics are a lot higher than mine, even measured on my lowly PII-366. I
thought BSD was supposed to be fast? In any case, there is no History Menu, so
we don't get the worst case, and the History Window is not considered an
often-used feature. My bookmarks menu is considered to be very exceptional,
catching many bugs that nobody else reported or could reproduce. Some of these
operations are not going to be quick in 6.0, but there are workarounds to
improve things, like using pgUp/pgDn
Reporter | ||
Comment 5•24 years ago
|
||
FYI, PgUp/Down is the same speed as clicking above and below the slider - ~4
seconds on my large-bookmark example, ~1.5-2 seconds on the small example (185
URL's - most of which are in the "standard" folders) - I only had about 40-50 at
the visible level.)
Comment 6•24 years ago
|
||
4 seconds per click? Are you measuring or estimating?
Reporter | ||
Comment 7•24 years ago
|
||
Measuring.
I just did a test in Manage bookmarks (default size; about 20-25 lines). Scroll
time was 3.0-4.2 seconds per click, averaging ~3.6. I opened it up to ~40-45
lines, and it takes 8.5-9.5 seconds per click....
In the History window (which is a little taller), it's 2.25-2.5 per click (no
folders to deal with though). I sized it even larger (from ~33 to ~45 lines)
and the scroll time went up to 3.4 seconds per click. At 6.5 lines, scroll time
is ~0.5 seconds. Hmmmmmmmmmmmmmmmmmm
Comment 8•24 years ago
|
||
What hardware, OS, etc?
Reporter | ||
Comment 9•24 years ago
|
||
FreeBSD 4.1-STABLE 20000910xx (pull/build). GCC 2.95.2
PIII-450, 256MB ram, 8GB IDE drive.
XFree86 3.3.5, TNT2 video card (Viper 770 I think)
.mozconfig:
# sh
# Build configuration script
#
# See http://www.mozilla.org/build/unix.html for build instructions.
#
# Options for 'configure' (same as command-line options).
ac_add_options --disable-pedantic
ac_add_options --with-pthreads
ac_add_options --enable-xterm-updates
ac_add_options --enable-debug
Comment 10•24 years ago
|
||
cc bryner & pavlov. Any idea why this is so much slower on FreeBSD? Do you
know of anyone we could assign this to?
Reporter | ||
Comment 11•24 years ago
|
||
for pollmann@netscape.com: could you try this with the bookmarks file above
under FreeBSD? Or point the people here at your freebsd machine so they can try
it?
Comment 12•24 years ago
|
||
*** This bug has been marked as a duplicate of 53051 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 13•24 years ago
|
||
reopening. This bug is specific to the bookmarks tree on BSD.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 14•24 years ago
|
||
I should note that this appears to affect all trees, not just bookmarks (though
bookmarks shows it more). History, for example, shows the same exponential
slowdown on larger windows.
Note that the fix for 53051 and 53091 doesn't solve this problem.
Useful tests needed: check on Linux, and run in a profiler with a LARGE
bookmarks window.
Keywords: qawanted
Reporter | ||
Comment 15•24 years ago
|
||
I finally got my Win32 dailys working again and checked there. The exponential
slowdown with larger windows IS present under Win32 2000092708, but the base
time is much faster, so a large window takes ~1sec to page up/down while a small
window is absolutely instantaneous, as best I can tell.
Setting OS->all, platform->all
Still looking for profile data. Anyone?
OS: FreeBSD → All
Hardware: PC → All
Comment 16•24 years ago
|
||
This tree scrolling slowness also makes the mail thread pane painful to use.
Comment 17•24 years ago
|
||
Build: 20001030.
I cannot drag/move bookmarks inside the folder "Imported IE favorites". My old
bookmarks file had about 500 bookmarks. This is on win 98, Pentium III-450,
256MB ram.
Also, there is no hourglass to indicate that Mozilla is doing something. An
hourglass would be nice so the user won't frantically click away at other
features while Mozilla is doing something, thus preventing Mozilla or the user
from getting confused and/or doing something they didn't want.
Comment 18•24 years ago
|
||
*** Bug 61643 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•24 years ago
|
||
FreeBSD 4.1 20010206xx
A quick re-check since I have a optimize no-debug build around.
It appears that lazy instantiation of treecells works - page-down on a large
window takes 1.2s initially, 0.7s the second time.
Timing appears to be closer to or even below linear with the number of lines in
the window. large-size (50) line window takes around 1.2-1.4 seconds, mid-size
(25) takes about 0.7 seconds, and small (10) takes .5 seconds. NOTE: this is
with a much smaller bookmarks file! I'll retry with a larger one.
I have not re-checked in History because it appears to be broken.
Comment 20•24 years ago
|
||
Reassigning to ben, who can fix this by converting to outliner.
Assignee: hyatt → ben
Status: REOPENED → NEW
Comment 22•24 years ago
|
||
nav triage team:
Outliner isn't coming for beta, marking nsbeta1-
Keywords: nsbeta1-
Assignee | ||
Updated•23 years ago
|
Whiteboard: [nav+perf]
Comment 23•23 years ago
|
||
*** Bug 72762 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
this depends on bug 73508 getting bookmark converted to use outliner widget.
Depends on: 73508
Comment 25•23 years ago
|
||
The BookmarksOutliner branch (rotted a little now, hoping to get back to it in
the next week or so) was showing scrolling speeds in my debug build faster than
that of my 6.1 optimized. Setting P2.
Status: NEW → ASSIGNED
Keywords: helpwanted
Priority: P3 → P2
Whiteboard: [nav+perf] → [nav+perf][ben-m5]
Target Milestone: --- → mozilla0.9.7
Comment 26•23 years ago
|
||
outliner fixes this, pretty much.
Assignee: ben → blakeross
Status: ASSIGNED → NEW
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.6
Assignee | ||
Comment 27•23 years ago
|
||
bookmarksliner is landing in --> 0.9.7.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Assignee | ||
Comment 28•23 years ago
|
||
fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•