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.

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

Changing QA contact

verified dupe of bug 69185.

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.

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

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.

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

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

no time; -> default owner

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!)

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.

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

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