Closed Bug 111821 Opened 24 years ago Closed 18 years ago

File Save As /Open dialog (filepicker) loads filenames very slowly

Categories

(Core Graveyard :: Talkback Client, defect)

Product:
Core Graveyard
Component:
Talkback Client
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ericweberg, Assigned: jay)

References

Details

(4 keywords)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: 20011112009 When saving files of any type (images, HTML pages, .txt), the list of existing files loads very slowly. It takes a few tenths of a second per file. The time to load the list becomes very frustrating at around 50 files, and gets worse from there. Reproducible: Always Steps to Reproduce: 1. Save any file or page in an empty folder. 2. Fill the folder with 50 or so dummy files. 3. Save another file. Actual Results: The file list loads slowly, taking about 2 seconds before I have control of the UI. Expected Results: Any File/Save dialog in Windows should open without noticeable delay. I've experienced this behavior on a P2-266 and a AMD Duron 700.
I've been disturbed by this too for a long time (850 MHz / 256 MB). The delay tends to become annoying when the directory contains more than 50 files or so.
Keywords: perf
-> file handing.
Assignee: dougt → law
Component: Networking: File → File Handling
QA Contact: benc → sairuh
ccing bryner... this seems like a filepicker issue...
Status: UNCONFIRMED → NEW
Ever confirmed: true
jrgm, have you noticed this?
QA Contact: sairuh → jrgm
I think I've seen this happen on occasion, but it isn't always a problem (I just tried with a couple hundred files with no delay). Either it's fixed or we need to hone in on the circumstances that expose this. Closing WFM unless I hear otherwise.
Target Milestone: --- → mozilla1.0.1
I downloaded todays version of mozilla. (Jan 31.) The bug was not apparent on NT4.0 with Netscape 6.21. On Win 2000 it loads fast the first time you open the dialog after a new start of navigator but is slow ever after.
*** Bug 129450 has been marked as a duplicate of this bug. ***
*** Bug 145279 has been marked as a duplicate of this bug. ***
Ooops! I finally found this damn bug! The issue is constantly present on two Win2k/sp2 machines I use (never saw it on Win98): a. AMD K6-III/400, 192MB ram, Voodoo3-2000 gfx card. b. P-II/400, 192MB ram, Matrox MGA G-200 on board. Can't be of minor severity. As originally reported, the performance hit is heavy when there are many files or folders in the dialog window (with 10 of them, the problem is already noticeable, with 20 is very annoying). Raising severity to normal.
Severity: minor → normal
I've had the same problem on my win2k sp2, PIII 500mhz and Mozilla 1.1alpha. Attaching or saving files in mails took awfully long. but I found a solution, quite accidently... I'm using Norton Antivirus 2002. it seems that there is a problem with Win2k and XP that the auto protect mode uses 95% of cpu all the time. (this is a known bug of symantec - though they don't know yet what causes it exactly). While most of the pc seemed to work fine (besides certain applications just taking longer to start up), some programs (and my hp 930) seemed to freeze totaly. Mozilla worked fine but the any file requester called from Mozialla showed the files very slowly. of course I did not connect that bug to Norton Antivirus right away. but as for NAV, I found that it seemed to have problems with virtualcd 4.01 (at least on my pc). after updating virtualcd to 4.04, NAV's auto protect mode dropped back to idle cpu usage. and since that Mozilla's requester works as fast as in any other application (even with folders with 300+ files). maybe this helps others to look for similar software set up (or high cpu usage with NAV).
Pascal, this is an issue with the CPU hogging apps running at the same time. The problem exists for me when I run SETI@Home. Even though I run it at a lower priority, somehow Mozilla does do this particular operation very slowly.
might well go into the same direction. it's just that mozilla as such did not seem to work much slower (or not really that I would have noticed). opening windows, accessing menues all worked well within mozilla - except the mentioned file requesters.
I experience the same problem with mozilla 1.1b, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722, on my linux box (Mandrake distro 8.2). My file system type is xfs.
I see the same slowness with Win/2K and Mozilla 1.1b. My guess at the cause would be that the control used to display file names is updating the screen each time a new name is added. Perhaps there's an option to delay updating until all file names have been added. Once all names have appeared, scrolling the display is fast.
*** Bug 121739 has been marked as a duplicate of this bug. ***
I can reproduce this bug. I currently have foldin@home installed as a service useing FireDaemon. It will take 3-11 sec per item in the save or open dialog box when ever folding@home is running but if I stop folding@home it imediatly speeds up. The dialog box looks windows generated. What is spawning this process(is this the right termanology). Is it specifying a proccessor priority. Does it defualt low if none is specified.
I am running an AMD K6-2 500 MHz machine (Windows 2000); 384 MG of Ram. When I right-click on a picture or a file, and choose the 'Save As' selection, the dialogue window will pop up and literally, a single item will reveal itself per (appromiately one) second. In addition, the Cancel and Save button are not shown and transparent. In addition, changing directories is a nightmare. I have tried unloading the system tray and the performance does improev, but unfortauntely, not by much.
Alijah, Alex: for your comments to be useful, you need to say what version/build of mozilla you're using. I used to see this sometimes, but I haven't seen it in the last couple of months (1.2alpha onwards...)
Confirming with Mozilla 20021114 from 1.2 brunch on Win2K. At the same time the same dialog works just perfect in IE and Opera on the same machine. It just soooo annoying in Mozilla to wait for directory to appear especially when comparing to other browsers.
Just wanted to say... using Phoenix 0.4 the file dialog is as fast as any other application. Maybe check what is different between Moz and the Phoenix branch when it comes to file dialogs?
Sorry. Build ID: 2002101808 Win2000 AMD 900Mhz 392MB Ram I have reorganized my download directory to where the top level is empty, except for folders. The problem is almost gone unless I move to other folders which have a large file count.
*** Bug 138719 has been marked as a duplicate of this bug. ***
Summary: File Save As dialog loads filenames very slowly → File Save As /Open dialog (filepicker) loads filenames very slowly
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1; MultiZilla v1.1.34 (d)) Gecko/20030221 Quite annoying when opening files on a network share. Opening a Linux directory via Samba that is an NFS mount from a third machine makes it really slow. Other Windows File Open dialogs on the same directory are much faster.
Keywords: regression
*** Bug 204730 has been marked as a duplicate of this bug. ***
Why does this bug keep bothering me? I have problems with a slow 'File', 'Save As' dialog since version 1.0 on my Windows 2000 1Ghz laptop. I happens when saving an attachment from the mail, but also when selecting a file location when downloading. At first it works OK. But after saving a couple of files (browser open for an hour) it becomes slow. It is hard to reproduce because it does not happen al the time...
"Me Too" Mozilla 1.4 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Windows 2000, HP Omnibook 500 laptop, 700mhz, 256 MB RAM Doesn't happen every time, but really annoying when it does.
The same observed on ix86 Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718). Saving any file took about 10 seconds on Athlon XP 1800+ with 512 MB RAM. After deleting downloads.rdf (about 4MB), files are saved without delay. Suggest to change OS to All.
Comment 27 has nothing to do with this bug; this bug is about the filepicker itself being slow; on open as well as on save.
You are right, I didn't notice the difference between this and bug 159107 (or bug 161783). I am sorry.
I'm still getting this behaviour. I had been told that it was caused by having too many entries in the download manager, but clearing that didn't seem to help, and now I can see why. Unfortunately, I can't get rid of my slopsucker, it's the main application I use on Windows (not that I'd mind dumping it and Windows both), so getting rid of the "100% CPU" process isn't going to do the trick. However, setting that process to "below normal" priority in Task Manager does the job, and doesn't seem to hurt its responsiveness (not that I'd expect it to). I'm surprised that Windows doesn't drop the priority of slopsuckers automatically. So... there's a workaround, ugly as it is.
*** Bug 219635 has been marked as a duplicate of this bug. ***
I'm experiencing the same problem. It does not appear to be related to any external applications. I can Install the build from August 1, 2003; this build has a very fast save as dialog (instantly responsive). Then I can install build September 15, 2003 (without rebooting or changing anything else) and the file save as dialog is very slow. And then again (without rebooting or changing anything else) I can install the build from August 1, 2003 and the file save as dialog is fast (instantly responsive). I know this dosn't help much but it is batting me drivey. Windows 2000 sp3 AMD 400 MHz 128MB RAM
retargeting
Target Milestone: mozilla1.0.1 → Future
.
Assignee: law → file.handling
Keywords: helpwanted
Target Milestone: Future → ---
I've noticed that saving files (opening Save As dialog) leaks memory. Most likely this is related to slowdown. I've opened some 40 JPEG images in the sequence and the memory usage was constant. But when I started to save these files (Save, Back, Save, Back, Save etc.) the memory usage started to grow.
Another important detail: If you save the same file some 20 times there won't be memory usage increase. But if you save different files (go back in history and save each of those files) then memory increase is present. Can someone check the memory usage on Linux/MacOS to make sure that only Win32 specific code is causing memory leak?
Memory leak was bug 198806. It is fixed in 1.6a
I just downloaded the latest nightly (Nov 14, 2003). That is the latest as of today (Nov 17, 2003). This build has an extremely fast File dialog. It still has some slowdowns when painting Icons, but when the icon is loaded all other files with the same icon draw very fast (instantly). This bug seems to be hit and miss. Most builds have it and some don't. Like this one (nightly Nov 14, 2003) is very acceptable.
Sorry for the 'me too' but I still see this in Mozilla 1.6, as I have for a long time and its the most annoying bug I know of thats left in Mozilla. It makes using it when I need to do a lot of opening of files locally in Composer extremely tiresome
Assignee: file-handling → win32
Component: File Handling → GFX: Win32
QA Contact: jrgmorrison → ian
It's back again. I have not had any problems with slow rendering of the filenames in the file dialog from (Nov 14, 2003) until now. I am using build 2004052808. It is very slow. The last version I have tested that did not have this problem was from nightly (2004-May-10).
yep. i'm seeing this again in 0.9. http://forums.mozillazine.org/viewtopic.php?p=601535#601535
*** Bug 245415 has been marked as a duplicate of this bug. ***
Has the filter string changed recently? It could make a difference.
Here we go again.... My Nightly build of mozilla from July 5, 2004 did not work very well. It was terribly slow at rendering the files in the file dialog. Now with the nightly from today July 12, 2004 the file rendering is very fast. I hope we can keep it this way. My current version is Mozilla 1.8a2 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040712 I hope someone can figure out what keeps changing to make the file rendering slow. And then stop changing it.
New twist. Now I'm back to a slow FileOpen dialog box. But with a twist... Now it is only slow on my networked/mapped drives. The local drives are fairly fast (not as fast as my previous version - 20040712) but fast enough. The network drives are very slow at rendering the files and folders inside the dialog box. Am I the only one experiencing this problem?
The same here with Firefox 0.9.1 and Windows 2000 SP4. The File Dialog is really slow in comparison with the ones found in other applications.
More of the same.... I tried the build from August 29 and it had a very slow file dialog box. Now I am running the build for today September 1 (2004090105). This one is quite fast. What ever has changed between august 29 and sept 1 could be the fix/break of this file dialog box (hint,hint - are there any developers who even care). I've narrowed it down to two days! If there are any developers who care about this problem I could try an August 30 build and narrow it down to only one day. Maybe we need to dig up an old 400MHz PC (like mine) and let the developers do their testing on it. Then they will see the problem and how annoying it is. I have to admit my friend's screaming 2.8GHz does not suffer from this problem. Allthough, it is slightly noticable. Here is some more info about the bug. 1) When file dialog box is slow a) processor usage goes to 100% until entire dialog box is rendered (10-30 seconds) 2) When file dialog box is fast a) processor usage goes to ~50% for less than 1 second. As far as I can speculate... 1) mozilla is filtering or analyzing the files as they are being displayed. 2) mozilla is spinning its wheels after opening the file dialog box. I believe 1) is more consistent with the nature of the bug. I feel this way because I have noticed that the file dialog (when it is in slow mode) is faster on a local file system than on a shared network drive.
Filtering is left to Windows. There are no recent changes to the filepicker code itself and I didn't find anything related in the checkins since August 29. I would like to have this problem fixed, but I haven't been able to reproduce it myself, which makes it pretty difficult.
Ere Maijala, Thank you for your reply. Every windows 2000 PC I have used (all 4 of them) have this problem. It is much less noticable on very fast PCs (like 1.2+GHz). And if you have lots of RAM (like 512MB), it is also less noticable. On these fast PCs with lots of RAM you would have to compare the two to see the difference. As I stated the version from August 29 has this problem. The best way to reproduce. 1) install a version with the bug 2) open the file dialog in a directory with lots of files (300 to 1000+ files) 3) stretch the file dialog to fill you whole screen (or most of it) 4) notice the time to render the dialog box 5) notice the cpu usage Then install a version without the bug and repeat steps 2 - 5 Again, todays build (Sept 1) does not have the bug. One other thing. The size of the install is much greater for the version that has the bug vs. the ones that do not. 08/30/2004 09:47a 12,529,312 mozilla-win32-installer(2004-August-29).exe 07/12/2004 11:50a 12,233,888 mozilla-win32-installer(2004-July-12).exe 09/01/2004 08:24a 12,228,768 mozilla-win32-installer(2004-Sept-01).exe Notice that the August build is ~300K greater than the other two. The other two are builds that I have saved that do not have the bug. I'll keep my eyes open and try to notice if there is a pattern here.
all (previous) talk of this bug appearing and disappearing with different builds seems to miss the point to me. I've seen this bug with every single release of Mozilla and Firefox for a long time. I use Windows 2000 with a 700MHz CPU and 256MB RAM. filepicker dialog boxes are always their default size. The bug has never been reliable enough to appear every tuim the filepicker is used, it comes and goes - you may see it but if you close that dialog down and re-do it the issue will be gone. I'll try one of the so-called 'fixed' builds and see what happens
(In reply to comment #50) > all (previous) talk of this bug appearing and disappearing with different builds > seems to miss the point to me. I've seen this bug with every single release of > Mozilla and Firefox for a long time. I use Windows 2000 with a 700MHz CPU and > 256MB RAM. filepicker dialog boxes are always their default size. The bug has > never been reliable enough to appear every tuim the filepicker is used, it comes > and goes - you may see it but if you close that dialog down and re-do it the > issue will be gone. > I'll try one of the so-called 'fixed' builds and see what happens Please post your results from using a build that I have stated is fixed. I am very curious to know how it works for you. I can say for a fact that I have never experienced this behavior. I have tried nightly builds at least once a month and most commonly 3-4 times a month for at least the last 2 years. Don't take me wrong. I'm not saying that the above does not happen on your PC. Just that I have never experienced it. Either the file picker dialog is slow or it is not. This is the behavior I always experience. I do admit that at times while accessing my local drives the file picker seems faster(just after a restart of mozilla or reboot). But after two or three times of opening the file picker dialog, it will be obviously slow (..with the builds that have the bug).
A few questions for those who see the problem: 1. Do you see heavy disk activity while the file list is being built? 2. Do you see it on Windows XP? 3. Do you see it with both load and save dialogs? 4. Does it matter what kind of files are there in the folder? 5. What file type have you chosen in the dialog (All Files etc.)?
There is on definite difference between the builds from August 31 and September 1. The later build doesn't containt Talkback. Now, could someone try removing the talkback related stuff from the slow Mozilla to see if it makes any difference? I believe the relevant files the the following in Mozilla/components directory: qfaservices.dll qfaservices.xpt BrandRes.dll fullsoft.dll master.ini talkback-l10n.ini talkback.cnt talkback.exe talkback.hlp Might be a good idea to delete compreg.dat too to make Mozilla update the components registrations.
I deleted the following files qfaservices.dll, qfaservices.xpt, BrandRes.dll, fullsoft.dll, master.ini talkback-l10n.ini, talkback.cnt, talkback.exe, talkback.hlp compreg.dat This make the file picker very fast. Just as fast as the Sept 1 build. Here are the answers to the previous questions (comment #52) a) build with _fast_ file picker b) build with _slow_ file picker 1. Do you see heavy disk activity while the file list is being built? a) Yes when the file list is not cached (ie the first time the file list is built) After that No. b) Yes when the file list is not cached (ie the first time the file list is built) After that No (but it is still slow?). 2. Do you see it on Windows XP? I did not do very much testing, but the short answer is No. 3. Do you see it with both load and save dialogs? a) Not relevant. b) Yes 4. Does it matter what kind of files are there in the folder? a) Not relevant b) No 5. What file type have you chosen in the dialog (All Files etc.)? a) Not relevant b) Doesn't matter. Tried All Files, HTML Files, ... XML Files.
Ok, no need to answer my questions if removing the talkback files does the trick.
Could someone else confirm what Jim experienced?
I am happy to confirm that, after deleting those files, file list is shown instantly ! (still wondering what it has to do with talkback). Tested with 20040903 Firefox/1.0 PR on Win2K-SP3, P4-2.4MHz.
Ok, then, what shall be done to fix the situation? Jay, any ideas or someone else to cc?
(In reply to comment #57) > I am happy to confirm that, after deleting those files, file list is shown > instantly ! Edit: I was too hurried to report. The speed-up was noted when I tried to download the same file (caching ?) The issue is still here and I am very sorry for the spam :-( As for the questions: 1. I don't see a disk activity even when monitoring with FileMonitor from Sysinternals. 2. I 'll check tomorrow. 3. Same perf problem with load and save. 4. Doesn't seem important. 5. Same behaviour when saving images, pages or loading with "All files" as default. Additionally, Task Manager showed only a short moderate increase in cpu activity (about 30%).
Today I reinstalled FF and deleted talkback files again. Now filepicker is instant. I don't know what to say (except that I am the dumbest tester at the moment).
I was kindly asked by Ere to repeat the test a few times (deleting all talkback files and compreg.dat). I did it six times. Test was done with Firefox aviary branch 20040903. Compreg.dat was always automatically recreated in both program (firefox\components) and profile (root level) directories. Both compreg.dat contain almost similar content but the one in the profile directory is slightly larger (133K vs 131K). Ere says the second file should not exist. In each of the above 6 tests, I checked filepicker performance on many directories. The improvement was evident each time the talkbalk files were missing. Now I am perfectly sure that talkback component is the cause. Another thing I noticed is the following. After creating quite a 45 dummy files and 145 sufolders inside a test directory, I noticed that the filepicker isn't slow on such a testcase. It seems that not only the number but also the size of the objects inside a directory matters. Or the fragmentation of the file system. Maybe this is why this bug is not visible by anyone.
> larger (133K vs 131K). Ere says the second file should not exist. I have to state that this was only my belief. Now that I think of it, it probably serves a purpose I'm just not aware of. Not that it changes anything regarding this problem.
(In reply to comment #61) >Compreg.dat was always automatically recreated in both program >(firefox\components) and profile (root level) directories. Both compreg.dat >contain almost similar content but the one in the profile directory is >slightly larger (133K vs 131K). Ere says the second file should not exist. ere, firefox uses "semi-single-profile" so that it can have profile-specific components (therefore generating profile-specific compreg.dat files).
Component: GFX: Win32 → Talkback
*** Bug 278912 has been marked as a duplicate of this bug. ***
1. Bug #268328 - probably duplicate 2. It happened in Mozilla 1.8a6 and 1.8b too, but deleting downloads.rdf (3KB ?) Fixed it.
Assignee: win32 → jay
QA Contact: ian → win32
Flags: blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4-
By the way, can we find a better component for this bug ? Why is it "Talkback Client" ?
Because the symptom is caused by Talkback. See comments #53 and #54.
*** Bug 361302 has been marked as a duplicate of this bug. ***
This bug is still present in Firefox 2.0 Talkback client -- confirmed. In safe mode, the bug is not present. With Talkback as the only active extension, it's present. With all my various extensions enabled EXCEPT Talkback, the bug is not present. Comment #6 I also confirm: > On Win 2000 it loads fast the first time you open the > dialog after a new start of navigator but is slow ever > after.
Keywords: qawanted
I suspect that our trunk nightlies no longer have this problem, since we've switched from Talkback to Crash Reporter. Can someone verify?
No longer blocks: 372972
I haven't noticed this bug in a very long time. Even with the 2.0 release versions, I have not seen it. I use Gecko/20070914 Firefox/2.0.0.7 and I often use the nightly builds. Then again, I've got a new computer since the last time I commented on this bug. Either it is fixed or my new computer is not susceptible to this bug.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007092405 Minefield/3.0a9pre ID:2007092405 In the latest nightly running on Vista, I am unable to reproduce this at all, even with up to 10,000 files in the same directory.
Resolving as WORKSFORME.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.