Closed Bug 506731 Opened 11 years ago Closed 5 years ago

Download manager uses a lot of CPU when active with multiple items

Categories

(SeaMonkey :: Download & File Handling, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: michael, Unassigned)

References

(Blocks 1 open bug)

Details

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
Version: unspecified → 1.9.0 Branch
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.
Depends on: 472001
Summary: Download manager uses a lot of CPU → Download manager uses a lot of CPU when active with multiple items
Version: 1.9.0 Branch → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-seamonkey2?
Flags: wanted-seamonkey2? → wanted-seamonkey2+
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.
Note that this is connected with bug 474626
Yeah, we should move the sorting discussion there and leave this open for now in case there are other outstanding performance issues.
Depends on: 474626
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).
Blocks: 523351
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.
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.
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.
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!
(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.
Depends on: 701051
Hi Michael, Tony, do you still see this problem in current SeaMonkey release?
Flags: needinfo?(michael)
Flags: needinfo?(acvickers1)
Whiteboard: [closeme 2015-07-01]
AFAICS this is fixed since quite a while.
Flags: needinfo?(michael)
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(acvickers1)
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2015-07-01]
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.
(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?
You need to log in before you can comment on or make changes to this bug.