Closed Bug 72482 Opened 23 years ago Closed 23 years ago

Save As dialog takes far too long to appear (file list loading too slow) (file picker)

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 75838
Milestone:
mozilla0.9.1

People

(Reporter: jg, Assigned: bryner)

References

Details

(Keywords: perf, topperf) 

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
Keywords: nsCatFood
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.
Keywords: mozilla0.9
accepting for 0.9.1
Assignee: bryner → bryner
Target Milestone: mozilla0.9 → mozilla0.9.1
Status: NEW → ASSIGNED
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
Closed: 23 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.