461617 - VERY SLOW and cpu-intensive deletion of many records from Download Manager list

Status: RESOLVED DUPLICATE of bug 380250

(SeaMonkey :: Download & File Handling, defect)

Description

[Fernando Cassia]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12

When you download files again and again over the course of many months, the Download Manager window might become very very long. In my case it had over 250 files I think.

In such situation, if you want to keep two or three entries but delete the rest, the normal procedure is to Select All, then Ctrl-click and de-select the two or three you want to keep listed in the Download Manager (for later reference or whatever). 

When you click "remove from list" CPU usage jumpts to 100% and the user interface stalls until the list has been "purged". This can take a LOT of time, and in my case took about 30 seconds with an unresponsive UI and CPU usage pegged at 100%. (This is a single core AMD Athlon 64 2.0Ghz with 1GB RAM)

I think the list purge algorithm could get a great speed-up by optimizing it. For instance if the number of entries you want to keep on the list is less than half, then it takes less time to build a list of entries to keep and build a new list of those to be kept rather than building a list of files to delete and then doing a lot of recursive delete operations.

Or, the download manager window could use a database rather than sequential operations which is what it feels like it's doing.

Reproducible: Always

Steps to Reproduce:
1. Fill your Download Manager window with 200+ entries
2. Select all but two or three entries
3. Select "remove from list"
Actual Results:  
Very S-L-O-W delete process. No progress or information dialog "Deleting entries, please wait"... nothing, just a stalled user interface with the button pressed down and you can't do nothing until it finishes.


Expected Results:  
Either:

1. Show a dialog and a quick progress bar showing the deletion process
2. Make the deleting process work in the background, returning control of the UI to the user
or
3. Use a database back-end for storing this information so that deleting entries on a long list isn't super-slow.

Comment 1

[Justin Wood (:Callek)]

Option 3 of your expected results will happen with Bug 381157 (Which is Blocking SM2)...

And probably will resolve these symptoms

Comment 2

[VRN]

I, too, have experienced this same problem.  I download hundreds of files, daily.  When I need to clean up the entries in the Download Manager, I need to be selective as to which entries stay and which ones get removed.  I use the same 'select and remove' method as was described by the original poster.  If I only delete a few entries at a time (like 10 - 20), it doesn't take quite so long, but it still runs the CPU up to 100% usage and can take up to three or four minutes.  (I am running a Pentium-3 1-ghz cpu.)  But when I attempt to delete several more (like 100+) from the list, I might as well go take a nap because it will probably take a half hour or longer to do the purge.  I can't imagine why this should be such a cpu hog for such a simple operation.

Comment 3

[Robert Kaiser]

Dupe of (i.e. resolved by) bug 380250 now that we landed bug 381157.