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.

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

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

See also bug 410538 and its associated bug trail.

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?

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

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);

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.

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?

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?

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.

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.

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