If you have a directory with, say > 200 items in it, and you hit File | Save As, and have the dialog load these 200 items for listing, it takes several orders of magnitude more time to display than 4.x did. Also, hitting the '..' button and viewing a parent directory with > 200 items in it takes nearly a minute (it felt long, no actual timings taken). It must be improved significantly to be taken seriously. Starting off in XPApps.
keywords. topperf since this hangs the product for ages while is displays the dialog. I hope this is a dup bug, cause it's been around a long time. Can't find anything already filed though.
Severity: normal → major
Keywords: mozilla0.9, perf, topperf
Save As loading a dir with 5036 items, it took 17 ses for the dialog to display. I hit the parent button and it took 1 minute 24 secs to display with 61 items (my home dir). Only difference between dirs other than number of items is that my home dir contains more directories and files with various extensions. The larger dir was mainly of one or two file types and a few sub-dirs but not many. K6-2 300Mhz, opt linux build from the tip recent. 256Mb RAM.
build from tip today, pII 400 with 256 ram: /dev with 2234 files loaded in 3-4 seconds
/dev with 1580 items loads in 4 secs. / loads in < 2 secs here with 23 items / from /dev (going up to parent) took 1 minute 24 secs. This is very strange,.
See also bug 70628. As far as I can tell, changing _from_ a directory with a lot of files to its parent or any subdir takes a serious perf hit...
Marking nsbeta1+, p2, mozilla0.9, reassigning to mcafee to have a look
Assignee: pchen → mcafee
Priority: -- → P2
Target Milestone: --- → mozilla0.9
Summary: Save As dialog takes far too long to appear → Save As dialog takes far too long to appear (file list loading too slow)
nscatfood. I was showing someone how to save pages to disk, and the wait to change directories was embarrasing - it would have been perceived as a hang by a normal user. I'm also resummarising.
nominating for moz0.9.1, per IM conversation w/mcafee. he also sez this is oughta go to ben [or, perhaps, alecf?], as this might be fixed by an outliner rewrite...
Assignee: mcafee → ben
Keywords: mozilla0.9 → mozilla0.9.1
File picker, I believe bryner was converting this to use outliner.
Assignee: ben → bryner
Component: XP Apps → XP Toolkit/Widgets
Er, sairuh, you're not supposed to remove keyword milestone nominations, ever :). Re-adding, sorry for spam.
accepting for 0.9.1
Assignee: bryner → bryner
Target Milestone: mozilla0.9 → mozilla0.9.1
Adding bug 75838, "rewrite file picker to use outliner", and adding "file picker" to summary.
Depends on: 75838
Summary: Save As dialog takes far too long to appear (file list loading too slow) → Save As dialog takes far too long to appear (file list loading too slow) (file picker)
I think that the correct solution would be to fix bug 80636 (and use gtk's native filepicker).
This should be fixed by the fix for bug 75838, if not please reopen. *** This bug has been marked as a duplicate of 75838 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
james, how is this working for you now that the new file picker has landed? gonna vrfy as dup --feel free to reopen.
Status: RESOLVED → VERIFIED
sairuh: while navigating through all the menus got much faster, the time until the "Save As" dialog appears is still too long (nearly a second on a P3-500). The same with "open file" and "open web location". Perhaps the bug should be reopened and the summary beeing changed, since only parts of summary are still a problem.
The Open Web Location dialog would be a completely separate issue (unless you mean hitting the Choose File button in that dialog).
OK, the original bug report should be considered fixed. As Boris pointed out, it mainly concerned leaving a directory that had a high number of files in it. For me, moving between directories is now of an acceptable speed (or at least, the only slow parts are the guis bits which tend to be slow throughout the app). I am, however, going to file a new, fresh bug on problems with very large directories. These continue to take orders of magnitude longer to display then 4.x. Bug number for that coming up shortly.
New bug concerns loading of large directories being very slow: bug 82854.
You need to log in before you can comment on or make changes to this bug.