If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Very slow "Save As" with "Web Page, Complete" option to USB drive

RESOLVED DUPLICATE of bug 623866

Status

Core Graveyard
File Handling
RESOLVED DUPLICATE of bug 623866
12 years ago
a year ago

People

(Reporter: matt, Unassigned)

Tracking

(Depends on: 1 bug, {perf})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

When i do a "file/save as" of the following page
http://trimpath.com/demos/nextaction_static1/nextaction.htm on my USB 2
thumbdrive, it takes 21 seconds (option Web Page, Complete) during which the
thumbdrive activity light is flashing like crazy.
If i use the html only option it takes only 2 secs. If i use a text editor to
save the same file it also takes 2 secs. As the content of the xxxx_files folder
is very small (146k) i would expect the time to save the file with the complete
option to be about 3 seconds.

I am fairly confident that the usb drive is ok (for instance it takes 8.5
seconds to transfer a 27 M° file).

If i make the same "file/save as" to a HDD, it is instantaneous.
If i make the same "file/save as" to a SATA drive, it is instantaneous.
If i make the same "file/save as" to a mapped HDD, it takes 1 sec.

Reproducible: Always

Steps to Reproduce:
1.load page http://trimpath.com/demos/nextaction_static1/nextaction.htm
2.start timer
3.do a file/save as to a usb thumbdrive
4.stop timer when firefox is active again (no more hourglass)

Actual Results:  
it takes 21 seconds to make the save during which time firefox is completely
blocked (hourglass)

Expected Results:  
it should take 3 seconds

Don't hesitate to contact me if you want me to make additional testing, i can't
debug the code but i can test ;=)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050803
Firefox/1.0+ ID:2005080310

WFM

<.5 secs

this is fixed in deer park
Whiteboard: dupeme
(Reporter)

Comment 2

12 years ago
i just tested with deer park beta 2, same result if not worse ...

11 seconds on a USB 1.1.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803
Firefox/1.0+ ID:2005080312
(Reporter)

Comment 4

12 years ago
I have confirmed the problem on another USB pen (a USB 1). I have the same
problem with both my home PC and my work PC. They are both XP/SP2 + firefox
1.0.6. I also add that the "optimize for performance" policy in the removable
hardware preference tab of XP has no effect.

Anyway, I have found a workaround for this bug, i have converted my usb pen to
ntfs and the problem disappeared. SO there is definitely something weird with
the way firefox and xp manage the cache writing.

Comment 5

12 years ago
Workaround:

A tip I just read somewhere said to clear your download history.  You can get there with control+J, and there's a convenient button to clear the history.  (I forget who/what should get credit because I got there from Digg.)

When I clicked the button, it hung both Firefox and my entiire machine, but when it finally got done, save-as complete took a reasonable amount of time.

I assume that I should do this procedure often if I want save-as to be useful

I'm surprised that this bug is "only" 8 months old because I'm sure that I've been avoiding FF for much longer than that because save-as was broken and unusable.

I'm saddened because this bug has no one working on it, that a feature whose use I don't see a use for is blocking a feature I want to use, and that two features could be so incompatible in a piece of software that's been around so long.

Comment 6

11 years ago
When I try to save web pages all firefox windows freeze (this not happen on Internet explorer)
To make an accurate assessment it STM you need to remove variability and test the component operations - i.e. save complete to HD and then measure the FIRST copy of nextaction.htm+nextaction(directory) from HD to USB.  And then measure save complete to USB using nextaction.htm loaded from HD.

So with reference to reporter only - save complete to a HD takes a second or two. copying those files with windows explorer from HD to a USB drive, FAT formatted, took me ~5 seconds or more.  Putting those measurements together there is no way a save to USB can be as fast as the 3 seconds you expect.  Add in variability for your internet connection and you are easily in the 10-15 second range or higher.  My save times using nextaction.htm loaded from HD were approximately the same using internet URL.


>As the content of the xxxx_files folder is very small (146k) i would expect the 
>time to save the file with the complete option to be about 3 seconds.

yes, if it were just a file copy, which this is not. When the page is loaded the page contents are retrieve "over the wire" to a large extent in parallel, not serially. But when you save the page I have not doubt the process is serial, i.e. slower.  Add a slow USB drive to a serial process and yes, you will see something slow.  Try saving it to a diskette to see what REALLY slow is.

-> INVALID, USB interraction is not a bug


I tested with USB2 and drive that is probably USB2 (not sure). USB 1.1 would obviously be much slower. FF and Seamonkey results are ~ same, I tested with FF trunk and SM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070109 SeaMonkey/1.5a

with reference to comment 1, I don't know what patch or bug Peter is referring to, and perhaps something was improved with a patch at some point.  If anything, non-USB aspects of this are related to bug 120809, bug 40867, and bug 115174 to name a few.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
Summary: Very slow "Save As" with "Web Page, Complete" option → Very slow "Save As" with "Web Page, Complete" option to USB drive

Comment 8

11 years ago
>> When the page is loaded the page contents are retrieve "over the wire" to a large extent in parallel, not serially. But when you save the page I have not doubt the process is serial, i.e. slower.

Why does the page need to be re-retrieved from the internet when it is saved?  Although I compare saves to disk, K-Meleon is much faster (nearly instantaneous) - maybe because it doesn't need to re-retrieve the page.
hmm, read the other bugs
Duplicate of this bug: 441869
see also
- bug 487375 for more info about USB performance
- bug 392728 about impact of RDF

Comment 12

9 years ago
Status... RESOLVED??? INVALID???...

Is not resolved. Firefox 3.1b3 still have that problem. Any version from 1 up to date had that bug.

Is not a Windows driver problem. Other browsers save pages just fine in the exact same USB pen drives.

Is not an USB bug. Is Firefox bug.
Flags: blocking-firefox3.5?
I'm certainly not an expert, and my analysis was a 2 years ago so the memory is faded. But if I recall correct, USB's performance characteristics (latency, etc) are exacerbated by poor general performance of Save As (bug 120809) - cited in comment 7, which is worth reading carefully.  And expectations of the reporter of this bug were/are certainly not realistic based upon that analysis, hence my closing it.  

Perhaps the effects of bug 120809 or others are even worse with DL manager. Perhaps Bug 441869 is valid on it's own. Can't say with 100% certainty without additional QA.  And you state 
a) "I had find this bug in more than 100 computers running Windows 9x, XP or Vista, with 5 pen drive models (any tested), and Firefox 1, 2, and 3. I never found an exception."
b) it doesn't happen on linux
c) it doesn't happen on windows with other browsers

So let's reopen, assume it is at least in part dependent on bug 120809, nd put it in component  file handling so we get more/better eyes on the problem. 

And to start, it would help if someone tests and stated real performance numbers for a, b and c above.
Status: RESOLVED → UNCONFIRMED
Component: General → File Handling
Depends on: 120809
Flags: blocking-firefox3.5?
Keywords: perf
Product: Firefox → Core
QA Contact: general → file-handling
Resolution: INVALID → ---
Whiteboard: dupeme
I restrained myself from citing this 2 years ago, but see also  Bug 198061 -  downloading / saving to floppy causes unresponsive UI

Comment 15

9 years ago
I had just tested this again:
Firefox 3.1b3, on windows XP sp3

Saving www.nytimes.com, to USB2 pen drive, froozed firefox for 10 seconds.
saving to hard disk, froozed 1 second.

There is no reason to have Firefox frozen only because a file is being saved.
Guillermo wrote: 

I tried to save www.nytimes.com using Firefox 10.0.2 both on HD and on USB pendrive. Obviously USB was lower than HD, but seems not to take so long as I
remember. I don't know if it was fixed, or now I just have faster USB
hardware. Anyways, entire Firefox remains non usable meanwhile saving
the page.

So I still consider an important issue, because lots of people in the
world, pay per time using Internet, and save web pages to be read
offline. Also, investigators frequently save pages, and time waiting
for pages saved adds to time unproductive.

Saving pages should be made in parallel, like downloading files. It
should not block the use of Firefox.
duping forward to bug 623866.  If problem not resolved when bug 623866 is fixed, then please reopen
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago6 years ago
Depends on: 623866
Resolution: --- → DUPLICATE
Duplicate of bug: 623866
(Assignee)

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.