Last Comment Bug 506731 - Download manager uses a lot of CPU when active with multiple items
: Download manager uses a lot of CPU when active with multiple items
Status: RESOLVED WORKSFORME
:
Product: SeaMonkey
Classification: Client Software
Component: Download & File Handling (show other bugs)
: Trunk
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 472001 474626 701051
Blocks: 523351
  Show dependency treegraph
 
Reported: 2009-07-27 13:18 PDT by michael
Modified: 2015-06-21 15:57 PDT (History)
8 users (show)
neil: wanted‑seamonkey2.0+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description michael 2009-07-27 13:18:39 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1

When using Seamonkey 2.0b1 and the download manager window is open with more than five downloads then the CPU usage goes up. I think that's because the update frequency is much higher than in Seamonkey 1.1.x.

Reproducible: Always
Comment 1 Robert Kaiser (not working on stability any more) 2009-07-27 18:28:41 PDT
It's probably mostly the sorting of the entries in the download manager, and we know it can be optimized quite a bit. IIRC, there was some talk about this in the bug I originally implemented the new UI in, but we concluded that it was better to get the new UI working and into the tree first before we optimize the sorting.

We currently re-sort the complete download list every time any active download triggers an update of its data, but when state doesn't change, we only need to re-sort active downloads and if we are sorted on a field that doesn't change during the download, we only need to re-sort anything at all when state changes.
We also could batch updates from multiple downloads in theory, but not completely sure how to do that, we probably could defer that into yet another bug.
Comment 2 neil@parkwaycc.co.uk 2009-08-02 16:52:56 PDT
I've come up with two possible tests we can do to avoid a full sort. The test goes in sortView just after the definition of compfunc. The first is this:

var sorted = true;
this._dlList.reduce(function(previous, current) {
  if (compfunc(previous, current) <= 0)
    sorted = false;
  return current;
}
if (sorted)
  return;

The second assumes you provide the index of the row you updated like this:

if (aRow >= 0 &&
    (aRow == 0 ||
     compfunc(this._dlList[aRow - 1], this._dlList[aRow]) > 0) &&
    (aRow + 2 <= this._dlList.length ||
     compfunc(this._dlList[aRow], this._dlList[aRow + 1]) > 0))
  return;

So it's more efficient but less readable. Note that neither of these options was the one I mentioned in bug 472001 where I suggest only invalidating the area between the row's original and target position, although the second option could be adapted to do so by virtue of saving the item originally at aRow and subsequently checking its new position.
Comment 3 Robert Kaiser (not working on stability any more) 2009-08-06 18:24:28 PDT
Note that this is connected with bug 474626
Comment 4 neil@parkwaycc.co.uk 2009-08-07 02:49:54 PDT
Yeah, we should move the sorting discussion there and leave this open for now in case there are other outstanding performance issues.
Comment 5 Robert Kaiser (not working on stability any more) 2009-10-20 07:00:36 PDT
OK, so let's make this bug deal with us actually doing the sort too often (we currently do a full sort on any update to any value in the tree, even when the tree is sorted by criteria that won't cause any sorting changes just on e.g. updating download progress), and file another followup on optimizing the sort itself (e.g. only resorting active downloads on progress updates and leaving inactive ones unchanged).
Comment 6 Tony Vickers 2010-09-18 09:05:17 PDT
I wonder if this bug is the reason why SM seems to freeze up when downloading new message headers in newsgroups. The whole system - browser and mail/newsgroups - become non-responsive for several minutes when a "get new messages" is requested from the ISP (Teranews.com) hosting the newsgroups.
Comment 7 Tony Vickers 2010-09-18 09:08:33 PDT
I might add that I don't see this behavior when getting the various Mozilla related news groups on mozilla.org. On Teranews.com, I am getting messages from about 40+ newsgroups, including various binary groups which seems to be the main hang up.
Comment 8 Robert Kaiser (not working on stability any more) 2010-09-18 09:13:31 PDT
Tony, no, download manager has no connection at all to getting newsgroup messages. The problem there is purely in newsgroup code, while this bug is about the download manager window UI only and only about the list of downloads shown in that window.
Comment 9 Tony Vickers 2010-09-19 13:56:11 PDT
Thanks Robert for the clarification. Similar code though? Just guessing on my part as I am not a programmer. You and the rest of the development team have done very well in keeping this project alive!
Comment 10 Robert Kaiser (not working on stability any more) 2010-09-19 14:47:15 PDT
(In reply to comment #9)
> Similar code though?

No, very different and completely unrelated code. Thanks for caring, though, as well as for the encouragement.
Comment 11 Phoenix 2015-06-17 06:27:54 PDT
Hi Michael, Tony, do you still see this problem in current SeaMonkey release?
Comment 12 michael 2015-06-17 07:38:10 PDT
AFAICS this is fixed since quite a while.
Comment 13 Tony Vickers 2015-06-21 14:34:26 PDT
I'm not seeing much of a problem with the current release I am using (2.26.1). I refuse to update until the image problem in newsgroups is fixed and not with a work around.
Comment 14 neil@parkwaycc.co.uk 2015-06-21 15:57:59 PDT
(In reply to Tony Vickers from comment #13)
> I refuse to update until the image problem in newsgroups is fixed
> and not with a work around.

Are you referring to the "work around" of using the old disk cache?

Note You need to log in before you can comment on or make changes to this bug.