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)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 38486

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.
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
Reporter, please try a more recent build. 1.6a is a bit old considering 1.6 final is "just round the corner"(tm).
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).
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.
Is this a duplicate of Bug #33269 (and ultimately Bug #38486)?
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.