Camino manages downloads slowly with a big download history

NEW
Unassigned

Status

Camino Graveyard
Downloading
12 years ago
8 years ago

People

(Reporter: vali.system, Unassigned)

Tracking

({perf})

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060821 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060821 Camino/1.0+

We you have a big download history (eg more than 400 entries), camino is very slow and uses 100% CPU for seconds at each start/end/stop/remove of downloads (PowerBook G4).
This might be link to the fact that i ever move files from download destination folder.
I could investigate much more, but i would not be surprise is the overhead is due to download.plist saving/updating ([NSDictionary writeToFile:atomically:]) on each operation.

Reproducible: Always

Steps to Reproduce:
1. Download many file
Actual Results:  
100% CPU for seconds at each start/end/stop/remove of downloads (PowerBook G4)

Expected Results:  
Download size history should (can) have a small inpact on download operations, but needs some caching.

Comment 1

12 years ago
I think you've probably guessed correctly at the source of the performance issue.

Whether or not this is a realistic "average" use case is a different matter. The "Remove Downloads on Quit" or "Remove Downloads on Successful Completion" options will obviate this problem for 99% of people.

Is there anything useful we can do to alleviate the problem for the edge cases?

cl
Related to bug 161783?

Comment 3

12 years ago
(In reply to comment #2)
> Related to bug 161783?

No, this implementation is Camino-specific.

Reporter, would it be possible for you to sample/Shark Camino for a couple of seconds while it's at max CPU, and attach the trace here?
I think there's an older bug about this issue, too (though it was fixed), or maybe that was just that cleaning up large lists was slow....
(Reporter)

Comment 5

12 years ago
(In reply to comment #3)
> (In reply to comment #2)
> > Related to bug 161783?
> 
> No, this implementation is Camino-specific.
> 
> Reporter, would it be possible for you to sample/Shark Camino for a couple of
> seconds while it's at max CPU, and attach the trace here?
> 

I'd be glad to send a Shark sample, but i stupidly removed my big download.plist. But i could edit one manually and copy and paste entries several time, it should reveal the same issue. Hum, to get a better test case  - more rendomized at least -, you can email me download.plist files.
(Reporter)

Comment 6

12 years ago
(In reply to comment #5)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Related to bug 161783?
> > 
> > No, this implementation is Camino-specific.
> > 
> > Reporter, would it be possible for you to sample/Shark Camino for a couple of
> > seconds while it's at max CPU, and attach the trace here?
> > 
> 
> I'd be glad to send a Shark sample, but i stupidly removed my big
> download.plist. But i could edit one manually and copy and paste entries
> several time, it should reveal the same issue. Hum, to get a better test case 
> - more rendomized at least -, you can email me download.plist files.
> 

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8.1b2) Gecko/20060821 Camino/1.0+
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8.1b2) Gecko/20060821 Camino/1.0+
> 
> We you have a big download history (eg more than 400 entries), camino is very
> slow and uses 100% CPU for seconds at each start/end/stop/remove of downloads
> (PowerBook G4).
> This might be link to the fact that i ever move files from download destination
> folder.
> I could investigate much more, but i would not be surprise is the overhead is
> due to download.plist saving/updating ([NSDictionary writeToFile:atomically:])
> on each operation.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Download many file
> Actual Results:  
> 100% CPU for seconds at each start/end/stop/remove of downloads (PowerBook G4)
> 
> Expected Results:  
> Download size history should (can) have a small inpact on download operations,
> but needs some caching.
> 

(In reply to comment #5)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Related to bug 161783?
> > 
> > No, this implementation is Camino-specific.
> > 
> > Reporter, would it be possible for you to sample/Shark Camino for a couple of
> > seconds while it's at max CPU, and attach the trace here?
> > 
> 
> I'd be glad to send a Shark sample, but i stupidly removed my big
> download.plist. But i could edit one manually and copy and paste entries
> several time, it should reveal the same issue. Hum, to get a better test case 
> - more rendomized at least -, you can email me download.plist files.
> 

Time profile for slow camino while removing an entry in a huge download history : http://www.valisystem.free.fr/bugzilla/TimeProfileofCamino.mshark

This is the full Shark sample while removing an entry in a 800 items list. I've invested it myself a little, and it seems to be more the way the list is managed than read/write operations of the download.plist file (bad habbit to blame Cocoa when something is slow ;) ).
I don't know Camino's code, but i would not be surprise if fixing it implies in depth modifications in the download list management. Instead of that work, I would suggest to limit size of download list, it could be a good alternative, but it's up to you.


Comment 7

12 years ago
Thanks for doing this legwork!  Do you think (if you haven't already deleted it) you could attach the plist here (using the create a new attachment link on this page, and probably compressing the hell out of it so bugzilla will take it) so we have a canonical "huge downloads file" to match our canonical "huge bookmarks file"?

Comment 8

12 years ago
The Shark trace shows that almost all the time is being spent in rebuilding the views for the list of entries (and AppKit trying to figure out which is the defaul t button as a result).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Summary: Camino manage downloads slowly with a big history → Camino manages downloads slowly with a big download history
I think Stuart and Nick were talking about rewriting this the other day....

Updated

10 years ago
Severity: minor → normal
You need to log in before you can comment on or make changes to this bug.