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)
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.
Comment 1•18 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
Comment 2•18 years ago
|
||
Related to bug 161783?
Comment 3•18 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•18 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•18 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•18 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•18 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•16 years ago
|
Severity: minor → normal
You need to log in
before you can comment on or make changes to this bug.
Description
•