download history loads very slowly

NEW
Unassigned

Status

()

Toolkit
Downloads API
11 years ago
7 years ago

People

(Reporter: Peter6, Unassigned)

Tracking

(Depends on: 1 bug, {perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

11 years ago
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.
Keywords: perf
Duplicate of this bug: 416111
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?
OS: Windows XP → All
Hardware: PC → All
Edward is the one who did the work on that - he's the better person to ask.

Comment 7

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

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

Comment 10

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

Updated

10 years ago
Depends on: 438342
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit

Comment 12

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

9 years ago
Another problem is that it's impossible to tell when the downloads window has finished loading.
You need to log in before you can comment on or make changes to this bug.