Closed Bug 349657 Opened 18 years ago Closed 9 days ago

Camino manages downloads slowly with a big download history

Categories

(Camino Graveyard :: Downloading, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: vali.system, Unassigned)

Details

(Keywords: perf)

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.
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?
(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....
(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 #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.


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"?
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....
Severity: minor → normal
Status: NEW → RESOLVED
Closed: 9 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.