133596 - Extremely slow rendering/repainting times for large file:// lists

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect, P3)

Description

[Nicholas Allen]

I have a local directory with about 2500 files in it.  Entering the directory 
as a file:// url in open location takes Mozilla 22 seconds to initially paint 
the screen.  Going to the parent directory and expanding as a thread takes 
Mozilla 17 seconds to initially paint.  In both cases, scroll performance is 
horrible - 4 or 5 seconds between updates.  Processor usage is 60-80% the 
entire time.  IE handles both of these perfectly - about 1 second to initially 
paint and multiple scroll updates per second.

Build 2002032203 Win2k.  Processor is 1.2 GHz Athlon.

Comment 1

[Bradley Baetz (:bbaetz)]

dupe of bug 69185.

file:/// listings should be html real soon, though - I have a patch for that
which I just need to fix for mac.

*** This bug has been marked as a duplicate of 69185 ***

Comment 2

[Christine Hoffman]

Changing QA contact

Comment 3

[Moied]

verified dupe of bug 69185.

Comment 4

[Nicholas Allen]

Reopening.  Pulled the latest bits after bug 69185 landed (via bug 110156) and 
the performance change is a wash.

Initial paint time using open location:

was 22 secs now 27 secs

Initial paint time when expanding as thread:

was 17 secs now 15 secs

Scrolling update speed:

was ~0.2 updates/sec now ~1.0 updates/sec

Not sure why time for open location spiked but everything else seems to work a 
little better with outliner changes.  Still about an order of magnitude away 
from being responsive though.

Bradley, if you think HTML file listings will kill this one for good, feel free 
to dupe to bug 102812 or appropriate.

Comment 5

[Bradley Baetz (:bbaetz)]

How many directories do you have in your root dir?

It still takes too long to list /dev, though - I should profile this again, I guess.

taking, and -> 1.1

Comment 6

[Nicholas Allen]

The url I've been using is file:///x:/Books/CRC%20Encyclopedia/math/a

Walking up that and not counting . or ..:

Entries URL
2513    file:///x:/Books/CRC%20Encyclopedia/math/a
27      file:///x:/Books/CRC%20Encyclopedia/math
6       file:///x:/Books/CRC%20Encyclopedia/
7       file:///x:/Books/
5       file:///x:/
14      (drive roots)

Everything in file:///x:/Books/CRC%20Encyclopedia/math/a is a regular file; 
everything above that is either a regular file or regular directory, mostly 
directories.  There's no symlinks, reparse points, directory mounted drives, 
quota'd areas, etc. that Mozilla could be choking on.

Comment 7

[Nicholas Allen]

Ok, put together a bigger torture test to make measuring against IE a little 
easier.

Open location with a file:// URL for directory with 62,205 files and 0 
subdirectories.  Time in wall clock seconds.

Browser                 Moz     IE6
Time rendering started  135s    8s
Time interface usable   190s    10s
Time CPU idle           630s    10s
Memory footprint        247M    16M
First scroll repaint    65s     Instant
Regular scrolling       Instant Instant

Moz = latest win32 nightly
IE6 = latest IE version
Time rendering started = time when window is first painted
Time interface usable = time when browser controls function
Time CPU idle = time when CPU usage went to 0%
Memory footprint = mem usage reported by task manager
First scroll repaint = time to repaint for the first scrolling adjustment
Regular scrolling = time to repaint for later scrolling adjustments

Comment 8

[Robert Kaiser]

On my PII-400 (448MB RAM) / Linux, that's what I see:

konqueror needs ~ 9-10 secs for loading /dev (2452 objects, that's files+dirs)

mozilla needs ~ 25 secs for the same directory on my recent build.

scrolling from top to bottom takes ~ 2 secs in any of the two.

Mozilla Mail/News, which uses the same tree, formerly outliner, implementation,
is showing a thread pane outliner with 3400 msgs at ~ 3 secs.

So what of this is loading time, what time do we need elsewhere? The new <tree>
is quite fast itself, as Mailnews shows...

Comment 9

[Bradley Baetz (:bbaetz)]

no time; -> default owner

Comment 10

[Andrew Simmons]

retested five years from the last post; no conclusions, just data points...

1. New laptop
==============
Intel Core2 T5600 1.83 GHz, 1Gb RAM. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2

68 seconds; the UI remained responsive whilst the page was loading.

Konquerer (3.5.4) - 45 seconds, but the UI froze until just before displaying the file listing.


2. Old desktop
==============
Intel P2/233MHz, 320Mb RAM. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070312
Minefield/3.0a3pre

5m 05sec. The UI froze completely (did not repaint after minimising and restoring the window) until the dir listing appeared, in one go. Firefox became so sluggish as to be virtually unusable however (>1m for screen refreshes)

Konquerer (): UI froze for 1m 30s; displayed a pageful of filenames; then appeared to freeze, although a progress bar kept moving. Slowly. It took ~25 mins for the progress meter to indicate the entire dir was displayed.



In each case, I created an identical test directory with exactly 62205 files (as per comment 7), with a very inefficient & slow perl one-liner that just did a crude 'date > file' to consecutively-numbered files (an artificial case, of course.) (data point - this took about ten minutes on the new machine but 
1h 20m on the old one!)

Comment 11

[Brent]

Bump!  This bug has been annoying me for 10 years!

On a 3GHz AMD Phenom II machine with 1858 files in /usr/bin, Firefox 10 (64bit version) still takes 6 seconds to populate a file dialog window.  Doesn't matter if I get to the dialog with "open with" for an email attachment (which is where I use file dialogs the most), or File->Open File.  ls in an xterminal takes 0.12 seconds to list all the files.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 14

[Andrei Purice]

Marking this as Resolved > Incomplete since the last real activity on this issue was 10 years ago (reported for Windows 2000) and it might not be relevant anymore.
Feel free to re-open it if it's not the case and the issue is still relevant.