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

Status: RESOLVED WORKSFORME

(SeaMonkey :: Download & File Handling, defect)

Description

[michael]

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]

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

[[e-mail]]

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]

Note that this is connected with bug 474626

Comment 4

[[e-mail]]

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]

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]

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]

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]

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]

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]

(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]

Hi Michael, Tony, do you still see this problem in current SeaMonkey release?

Comment 12

[michael]

AFAICS this is fixed since quite a while.

Comment 13

[Tony Vickers]

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

[[e-mail]]

(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?