228748 - back button usage is very slow, causes CPU usage to spike

Status: RESOLVED DUPLICATE of bug 38486

(Core :: DOM: Navigation, defect)

Description

[Mike Sugimoto]

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.

Comment 1

[Mike Sugimoto]

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

[Robert Accettura [:raccettura]]

Reporter, please try a more recent build.  1.6a is a bit old considering 1.6
final is "just round the corner"(tm).

Comment 3

[Mike Sugimoto]

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

[Robert Accettura [:raccettura]]

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

[firemotion+mozilla]

Is this a duplicate of Bug #33269 (and ultimately Bug #38486)?

Comment 6

[Robert Accettura [:raccettura]]

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 ***