Closed
Bug 228748
Opened 21 years ago
Closed 21 years ago
back button usage is very slow, causes CPU usage to spike
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: phloem, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029
For all web pages visited, use of the back button (or page selection off of "Go"
dropdown menu item) results in CPU usage jumping to 100% for a period
proportional to the number pages backed up over. (i.e., moving further back in
the history results in a longer period of time at 100% CPU.) The transition to
the new page is very slow, and seems again to be proportional to the number of
pages being traversed (~1 second/page).
Reproducible: Always
Steps to Reproduce:
1. Load random page.
2. Follow a couple of links.
3. Use drop-down from back button or Go to back up to first page loaded.
4. Watch CPU usage spike. Wait.
Actual Results:
Very slow navigation between pages, CPU usage goes way up.
Expected Results:
CPU usage probably shouldn't spike, and it probably shouldn't take ~10 seconds
to back up nine pages in the history.
There doesn't seem to be an inordinate amount of swapping going on -- this
machine has 512M of memory but is using only ~70M of swap on an 1800 MHz Athlon
running a pretty stripped down 2.4.22 kernel. No other applications seem to have
speed problems.
Moving forward in the history list does not seem to be affected by this slowdown
(and does not cause the load average to jump).
This has been happening since at least 1.4 and became very noticable under 1.5.
It seems much, much worse with 1.6a than it ever did.
Reporter | ||
Comment 1•21 years ago
|
||
Stack trace from a sample run (backed up over five pages):
execve("/usr/bin/mozilla", ["mozilla"], [/* 42 vars */]) = 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
98.34 0.980028 44547 22 11 wait4
1.00 0.009998 9998 1 execve
0.46 0.004599 418 11 fork
0.08 0.000774 18 43 4 read
0.04 0.000364 1 347 rt_sigprocmask
0.02 0.000241 13 18 2 open
0.02 0.000185 9 21 5 stat64
0.01 0.000106 11 10 pipe
0.01 0.000100 3 36 close
0.01 0.000060 3 22 old_mmap
0.00 0.000036 0 80 brk
0.00 0.000024 0 51 rt_sigaction
0.00 0.000017 3 6 munmap
0.00 0.000012 2 6 mprotect
0.00 0.000010 1 10 _llseek
0.00 0.000010 1 14 fstat64
0.00 0.000009 1 11 4 sigreturn
0.00 0.000009 9 1 lstat64
0.00 0.000006 2 3 chdir
0.00 0.000005 3 2 dup2
0.00 0.000004 1 4 fcntl64
0.00 0.000003 2 2 2 ioctl
0.00 0.000002 1 2 uname
0.00 0.000002 1 2 getgroups32
0.00 0.000001 1 2 time
0.00 0.000001 1 2 getpid
0.00 0.000001 1 2 getpgrp
0.00 0.000001 1 2 getrlimit
0.00 0.000000 0 2 getppid
0.00 0.000000 0 2 getuid32
0.00 0.000000 0 2 getgid32
0.00 0.000000 0 2 geteuid32
0.00 0.000000 0 2 getegid32
0.00 0.000000 0 1 1 semget
------ ----------- ----------- --------- --------- ----------------
100.00 0.996608 744 29 total
Comment 2•21 years ago
|
||
Reporter, please try a more recent build. 1.6a is a bit old considering 1.6
final is "just round the corner"(tm).
Reporter | ||
Comment 3•21 years ago
|
||
Still present in 1.6b/2003121012, with the added bonus that now the browser's
slow moving forward, too (and seems to get worse if any browser window has
multiple tabs open).
Comment 4•21 years ago
|
||
It will most likely get slower if more tabs are open. The more ram used by the
browser, will result in decreased performance, especially noticable on older
computers.
Comment 5•21 years ago
|
||
Is this a duplicate of Bug #33269 (and ultimately Bug #38486)?
Comment 6•21 years ago
|
||
Yes, this bug matches bug 38486 very well.
resolving as duplicate.
If someone can bring to light something showing otherwise, we can reopen this,
but all comments point to bug 38486.
*** This bug has been marked as a duplicate of 38486 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Component: History: Session → Document Navigation
QA Contact: docshell
You need to log in
before you can comment on or make changes to this bug.
Description
•