The default bug view has changed. See this FAQ.

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

RESOLVED WORKSFORME

Status

SeaMonkey
Download & File Handling
RESOLVED WORKSFORME
8 years ago
2 years ago

People

(Reporter: michael, Unassigned)

Tracking

(Blocks: 1 bug)

Dependency tree / graph
Bug Flags:
wanted-seamonkey2.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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
(Reporter)

Updated

8 years ago
Version: unspecified → 1.9.0 Branch

Comment 1

8 years ago
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

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-seamonkey2?

Updated

8 years ago
Flags: wanted-seamonkey2? → wanted-seamonkey2+

Comment 2

8 years ago
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

8 years ago
Note that this is connected with bug 474626

Comment 4

8 years ago
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

Comment 5

8 years ago
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).

Updated

8 years ago
Blocks: 523351

Comment 6

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
(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.

Updated

5 years ago
Depends on: 701051

Comment 11

2 years ago
Hi Michael, Tony, do you still see this problem in current SeaMonkey release?
Flags: needinfo?(michael)
Flags: needinfo?(acvickers1)
Whiteboard: [closeme 2015-07-01]
(Reporter)

Comment 12

2 years ago
AFAICS this is fixed since quite a while.
Flags: needinfo?(michael)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(acvickers1)
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2015-07-01]

Comment 13

2 years ago
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.