small chunk sizes results in bad performance when saving attachments to USB-stick

NEW
Unassigned

Status

()

Firefox
File Handling
--
minor
7 years ago
a year ago

People

(Reporter: m.gedig, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11

When Saving attachments out of the SeaMonkey EmailClient to an USB-stick, the client becomes unresponsive and the process is very slow (6KB/s). This does not happen when storing to the HD.

Reproducible: Always

Steps to Reproduce:
1. Receive email with attachment of noticeable size (> 1/2 MB) and mount USB-flash-memory-stick
2. Select "Save" from the attachment-context-menu
3. Wait and observe speed much lower than what the Stick is capable of and unresponsiveness of client and download manager.
Actual Results:  
It took 17 minutes to store/export/save an attachment
not touching the system it works out fine.
High CPU load at times.

Expected Results:  
storing at 8MB/s

none

Comment 1

7 years ago
Possible duplicates and similar issues:
Bug 587724 - Mozilla becomes unresponsive during USB file transfers
Bug 303268 - Very slow "Save As" with "Web Page, Complete" option to USB drive
Bug 487375 - Severe performance issues on USB stick while deleting or receiving mail
(Reporter)

Comment 2

7 years ago
For some reason I didn't find any good matches prior to entering, but:
Bug 303268 and Bug 587724 are similar.
The issue seems persistent.
My Thumbdrive isn't slow (reads 26MB/s) but
it is FAT32 formated
Keywords: perf
Version: unspecified → SeaMonkey 2.0 Branch
There is another report about saving over network in Firefox that I can't find at the moment. It seems that Gecko stores the files in very small chunks with hurts the performance on the network and might be the reason why some USB Sticks are slow.

Comment 4

7 years ago
According to sid0, it's the chunk size used to stream the file/attachment out to disk/whatever.
(Reporter)

Comment 5

7 years ago
That sounds very plausible and should not be that hard to change.
In an other related bug-report I read, that it doesn't happen with NTFS formated drives. After some trouble I was able to format the Drive using NTFS with 8KB cluster-size. The problem is gone! One might argue that this is a windows issue, but I doubt MS will do anything about it. Mozilla should make sure data is written asynchronously in chunks >4KB.
THIS SEEMS LIMITED TO FAT32
since I was unable to use exFAT under WinXP-Home I can not say anything about it.
moving to core:File handling and confirming
Status: UNCONFIRMED → NEW
Component: Download & File Handling → File Handling
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: download → file-handling
Summary: Saving attachments out of the SeaMonkey EmailClient to an USB-flash-memory-stick - slow → small chunk sizes results in bad performance when saving attachments to USB-stick
Version: SeaMonkey 2.0 Branch → Trunk

Comment 7

7 years ago
> Mozilla should make sure data is written asynchronously in chunks >4KB.

The relevant code in nsExternalHelperAppService.cpp is:

155 // Buffer file writes in 32kb chunks
156 #define BUFFERED_OUTPUT_SIZE (1024 * 32)

and that's exactly what we do right now.  That's _if_ this is using the exthandler code.  If it's not, then what code is it using?  Philip?

Comment 8

7 years ago
I've asked someone in #maildev to answer this (I think we have two code paths in MailNews depending on *how* you save attachments - bleah!).
(In reply to Philip Chee from comment #8)
> I've asked someone in #maildev to answer this (I think we have two code
> paths in MailNews depending on *how* you save attachments - bleah!).

Philip, do you call the results of that conversation?

http://tinyurl.com/6m6qy6t is a revision of my query from bug 487375 comment 9

Comment 10

6 years ago
Sorry I can't remember if there was any reply to my query.
Blocks: 303268
Duplicate of this bug: 303268

Comment 12

2 years ago
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #9)
> (In reply to Philip Chee from comment #8)
> > I've asked someone in #maildev to answer this (I think we have two code
> > paths in MailNews depending on *how* you save attachments - bleah!).
> 
> Philip, do you call the results of that conversation?
> 
> http://tinyurl.com/6m6qy6t is a revision of my query from bug 487375 comment
> 9

This is an old news.

If you click on the attachment icon, it invokes one code path.
If you click on "Save" button in the right hand side at the bottom of message window,
then it invokes ANOTHER code path.

I think the one that is invoked by clicking the icon has a reasonable buffer size now, but I have not checked lately.
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.