413209 - download history loads very slowly

Status: NEW

(Toolkit :: Downloads API, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011909 Minefield/3.0b3pre ID:2008011909

repro:
get a long list of downloads
open DM

result:
in my case, with only 90 downloads in the list, it takes about 10 seconds before they are loaded.

Comment 1

[Antti Tervasmäki]

Just measured: 50 seconds, about 500 downloads in list..
So 100 in 10 seconds seems to the rate here...

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011910 Minefield/3.0b3pre ID:2008011910

Comment 2

[Shawn Wilsher :sdwilsh]

This is the expected behavior.  We slowly build the list so we don't kill the UI thread when it builds otherwise.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

See also bug 410538 and its associated bug trail.

Comment 5

[Justin Dolske [:Dolske]]

Taking over a minute to fully show a UI shouldn't just be considered expected-behavior. It's taking about 30 seconds for me, and Mossop said it's 100+ seconds for him.

toolkit/mozapps/downloads/content/downloads.js indicates that the DM is configured to add only 3 entries every 300ms. That seems extremely low, but was bumped down from 10 per 100ms in bug 408745, so I'm not sure what the history here is.

Why was this set so low? Awesomebar is able to interactively search with chunks of 1000 every 100 ms, and that seems responsive. Is DM hitting perf issues due to obtaining results, displaying results, or a mix? Any profiling to help narrow down where the bottleneck is?

Comment 6

[Shawn Wilsher :sdwilsh]

Edward is the one who did the work on that - he's the better person to ask.

Comment 7

[Ed Lee :Mardak]

The sql query itself is fast. I believe the bottleneck is creating the richlistitem. Each item does try displaying a file icon as well.

Would someone be able to shark this?

start around
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/content/downloads.js&rev=1.148&mark=1125#1125
function buildDownloadList(aForceBuild)

end around
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/content/downloads.js&rev=1.148&mark=1185#1176
notifyObservers(window, "download-manager-ui-done", null);

Comment 8

[Ed Lee :Mardak]

A very crude dumping of time diffs for stepListBuilder..

pre-step: 0 // gets big every 3 because of the timeout
post-step: 1
post-attr: 4
pre-create: 1
post-create: 14 // createDownloadItem does some work creating richlistnode
post-match: 2
post-append: 65 // gDownloadsView.appendChild(item) does quite a bit of DOM
post-stripe: 3
post-updatebutton: 3

arguably we could make the timeout smaller or do more in a chunk.. But too many in a chunk means we hit several append costs in a row.

Comment 9

[Justin Dolske [:Dolske]]

I assume those times are in ms?

Skimming through createDownloadItem(), it looks fairly sane, although there's a fair chunk of code being run for each item. Maybe there's some perf tuning that can be done in there.

But most of time is spend in appendChild(), and I'm not sure how to make that go faster. I presume most of that time is in XBL binding and DOM overhead?

Neil, any ideas?

Comment 10

[Ed Lee :Mardak]

I suppose we could try simplifying the binding? Is it just the binding content we should be worried about being too complex? (I don't think there's much that can be removed when keeping the same format for all bindings.. perhaps individually for just download-done..

chrome://mozapps/content/downloads/download.xml#download-done
it extends
chrome://mozapps/content/downloads/download.xml#download-base
which has a few properties.. but those are only used on access?

Comment 11

[Justin Dolske [:Dolske]]

I suspect a lot of the overhead is just because there *is* a binding. I've run into this before in an extension, tried a variety of tricks, but wasn't able to get it to perform fast [and ended up doing chunking just like is done here :)]. FWIW, I had also tried creating a "template" dom fragment and then using a deep cloneNode to glue it on repeatedly... IIRC it was only a bit faster, but was certainly messier.

Comment 12

[James May [:fowl2]]

Instead of lazy (and slowly) loading the whole list, just the active downloads + 50 could be loaded with a "Show x more items..." link at the bottom.

Comment 13

[James May [:fowl2]]

Another problem is that it's impossible to tell when the downloads window has finished loading.