326405 - Download Manager slow to open (+CPU hog) with many items in download history

Status: RESOLVED DUPLICATE of bug 161783

(Toolkit :: Downloads API, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

If you have many items in your download history (say 10 items are much more ...maybe 50+), download manager slow down considerable and will cause high CPU utilization and disk thrashing when either you are trying to download a file or you are simply trying to open the download manager from Tools -> Downloads. 

Reproducible: Always

Steps to Reproduce:
1. Generate a clean profile
2. Configure Download Manager so that it does not clear it contents automatically, and also that Download Manager should close upon completing a download.
3. Visit a site with a lot of small files (say 50 or more) and download them in order to create a download history.
4. Close Download Manager, if it is open.
5. Download some more files, but this time observe how long it takes Download Manager to open for each file you attempt to download + the CPU usage.
6. Continue to fill up the download history with another 50 or so items.
7. Manually open Download Manager via Tools -> Downloads and observe how long it take + the CPU usage involved.

Actual Results:  
Download Manager takes way too long to appear, because the CPU utilization gets maxed just trying to display it.


Expected Results:  
Download Manager windows should appear quickly and with little strain on the CPU.

Comment 1

[IU]

Was originally reported as part of Bug #311181, which I will now close. 

Comment 2

[zug_treno]

Marking as duplicate of bug 161783 (based on its other duplicates), see also Suite bug 159107.

*** This bug has been marked as a duplicate of 161783 ***

Comment 3

[Elmar Ludwig]

Bug 240525 would perhaps be more appropriate, unless 161783 is moved to the Core product. But bug 161783 better describes the underlying problems, so it doesn't really matter...