145851 - Very slow file saving

Status: RESOLVED DUPLICATE of bug 159107

(SeaMonkey :: Download & File Handling, defect)

Description

[Eugene (Gene) Pizzetta]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051021

Using "Save Image" or "Save Link Target" or "Save Page As" there is a pause of 1
or 2 seconds before the file dialog appears and a similar but often longer pause
before the file save message box appears. It is frustratingly slow.

This problem does NOT exist in the Windows version of Mozilla, or it the OS/2
version of Netscape 4.61.

Reproducible: Always
Steps to Reproduce:
1.For instance, right click on an image.
2.Click on "Save Link Target As"
3.After 1 or 2 second pause, file dialog displays. Click on "OK."


Actual Results:  After 1-3 second pause, file saving progress box finally appears.

Expected Results:  The progress box should have appeared immediately.

Comment 1

[Mike Kaply [:mkaply]]

How many files have you downloaded?

As the download manager gets more and more full, opening the save dialog becomes 
slower.

Comparing to Windows is only valid if you have downloaded a lot of files in 
Windows as well.

Comment 2

[Eugene (Gene) Pizzetta]

My real issue here is the saving of the file. The file dialog will take longer
to display, I suppose, as more files are added to the download directory. The
slowness is consistent in that it is *always* slow. For instance, last night I
downloaded a Java update from IBM which was about 20 MB. About 1 MB had already
been downloaded before the progress window appeared.

When saving a page or simple graphic, a similar delay occurs every time, not
just after downloading several files. On small graphics the progress dialog will
merely flash on and off the screen, sometimes not drawing completely, but it
still take too long to appear.

The difference from Windows Mozilla or OS/2 Netscape is quite dramatic and
easily observed. I'm using JFS if that could be a factor, but I doubt it.

I have a DSL connection; the problem may be less obvious with a dialup.

Comment 3

[Achain]

This seems download manager issue for me as Mike mentioned.
Whether we use download manager or not, downloads.rdf (is in directory
where prefs.js is) get larger per downloading. And large downloads.rdf
takes long time to be processed at next download.

Eugene, please try:
1) Open download manager (Tools - Download Manager).
2) Press Ctrl-A to select all list.
3) Press "Remove from List".
then run another downloading. It shuld not have delay.

Comment 4

[Mike Kaply [:mkaply]]

Eugene:

Please put your downloads.rdf on Windows and see if it has the same problem.

As I pointed out, you are comparing apples and oranges.

Comment 5

[Eugene (Gene) Pizzetta]

OK, now we've found the problem. The download.rdf file was 1.6 MB's. The
contents went back a long way to some old betas and web sites I don't remember.

I tried the suggested procedure: opening the download manager, Ctrl-A, remove
from list. Mozilla locked up and CPU usage went to maximum. Luckily I could kill
it via the Warp Center kill list. I tried a second time with the same result.
But I was able to go into the profile directory and delete the download.rdf file.

That solved the problem. Downloads are now normal. Thanks.

But shouldn't that file be trimmed automatically? Or does it continue to grow
until it's cleared manually? Or maybe some beta damaged it so it couldn't be
trimmed or cleared?

Comment 6

[Achain]

Trimming of doenloads.rdf is on the stage. (bug 141794)

When I did "Remove from List" a month ago, it took 10 or more minutes to
complete. Size of downloads.rdf was around 1 MB...I don't remember well.
Anyway, "Remove from List" was terribly slow to a large downloads.rdf.
Your mozilla might not lock up but be processing verrrrry slowly.
The slowness may be a bug to fix, but it is hard to create a large
downloads.rdf for examination...

Comment 7

[Mike Kaply [:mkaply]]

I'm marking this all to get some traction on it.

Is this happening on other platforms?

Comment 8

[Achain]

My downloads.rdf is raised to about 250kB (500 entries).
On both OS/2 and Win32 trunk build (on PII-400 box), the delay time
from pressing OK on file dialog to starting download is less than 1 sec.
I think this is reasonable time for the downloads.rdf.

And both builds take over 3 minutes to complete "Remove from List".
Oops, I find this topic is also already on stage as bug 132013.

Comment 9

[Eugene (Gene) Pizzetta]

I did a little experimenting. After selecting all entries in the download
manager, with a download.rdf file of about 170Kb, it takes about 2 minutes for
the download manager to "remove from list." All other activity must stop during
this period because CPU usage goes to 100%.

However, although the list is cleared, the download.rdf file remains as it was.
It is not removed or truncated.

*Additional downloads are added to the entries still in the download.rdf file.
It is necessary to manually delete download.rdf to get rid of it.*

Slow saves apparently don't occur until the file becomes quite large -- probably
a megabyte or so -- but all users will experience the problem eventually unless
the download manager is fixed.

By the way, you guys have done a great job on Mozilla. I've been using it
instead of Netscape 4.61 since beta 0.98.

Comment 10

[Horste]

This is the only thing I really hate on the Mozilla/Netscape browser.
On my slow Mac (G3/233) it takes a long time from starting the saving to the 
display of the dialog informing about the saved file / progress.

Wouldn't it be better to have a simple "Save" function that simply saves to the 
location set by the last "Save As" dialog, without displaying anything. 

BTW the sequence how the savedialog is displayed, seams to be wrong. On the mac 
first the saving seams to occure, then the dialog is built up. The dialog is 
displayed for a such a short moment (completely useless, because you cannot 
read what is displayed) and then it still takes time to build down the dialog.  

Comment 11

[TGOS]

Has someone already filed an own bug because removing entries from the download
manager is horrible slow and one because the RDF file is not trimmed in size?
Somehow I think the whole implementation of the list is buggy, as the list gets
slower the more you add and it is horrible slow to remove something.

Comment 12

[Joseph Doer]

I had a 3MB download.rdf file and the download/saving went realy slow. I removed
the file out of my profile and voila fast again. :)

I have Mozilla 1.2.1 on Win2k on the run. 

Comment 13

[Andreas Kunz]

*** Bug 186931 has been marked as a duplicate of this bug. ***

Comment 14

[Andreas Kunz]

The duplicated bug was on MacOS, downloads.rdf size: 1.6 MB. So this is really
cross-platform.
I'm doing some testing with a artificial downloads.rdf file now and am going to
confirm this bug afterwards (depending on the result).

Comment 15

[Andreas Kunz]

Bug 159107 has been filed after this one, but there are many more people on the
cc list (more attention from developers), so I mark this bug as duplicate of the
other one. 

I'll attach my test results there.

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