Opening download manager takes way too long

VERIFIED FIXED in mozilla1.9beta3

Status

()

Toolkit
Downloads API
P3
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Jesse Ruderman, Assigned: Mardak)

Tracking

({perf, regression})

Trunk
mozilla1.9beta3
perf, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Opening the Download Manager (with Cmd+J) takes 7 to 9 seconds in the 2007-11-15 nightly.  In the 2007-11-11 nightly, it only takes 1 second with the same profile.
Flags: blocking-firefox3?
TLD information?
(Assignee)

Comment 2

10 years ago
How many entries do you have showing up? Is it just opening or is it also searching?

If I search for 'a', it returns all 150 downloads in about 1-1.5 seconds for me.

Opening is almost instantaneous for me, but that only shows 8 entries.
(Reporter)

Comment 3

10 years ago
About 100 entries show up when I open download manager.  I don't think it's searching, just showing the most recent downloads.

Searching is also slow, even when only a few entries match.

What is "TLD information"?
(Assignee)

Comment 4

10 years ago
We recently started showing the eTLD+1 for finished download.

The new designs seem to point to showing all downloads by default, so I'm guessing whatever slowdowns you see now for the 7 days of downloads will only get worse.

But I'm still not sure what would be causing the issue.. Do you have a lot of downloads whose corresponding file is deleted?

You're running on a macbook pro?
Keywords: qawanted
(Reporter)

Comment 5

10 years ago
I have deleted or moved most of the files I have downloaded.  Many of them have identical filenames.

I'm running Tiger on a MacBook Pro.

Updated

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P3
Target Milestone: --- → Firefox 3 M10

Comment 6

10 years ago
Edward can you take this?
Assignee: nobody → edilee
(Assignee)

Comment 7

10 years ago
This will probably be addressed with bug 392097 which will make all the downloads show up instead of just 7 days, so the problem will only get worse.
(Assignee)

Updated

10 years ago
Depends on: 392097
(Assignee)

Comment 8

10 years ago
Actually.. perhaps part of the overhead is initializing the download manager backend -- not just displaying the items.

So if we figure out something for bug 399838, it might help as well.
(Assignee)

Comment 9

10 years ago
Jesse, do these builds take a long time to open the download manager as well?

https://build.mozilla.org/tryserver-builds/2007-12-03_23:46-edward.lee@engineering.uiuc.edu-fastdlmgr/

First time opening vs second time?
(Assignee)

Comment 10

10 years ago
Jesse: Here's a build that shows 1 item then 10 at a time. Is the download manager still slow to open?

https://build.mozilla.org/tryserver-builds/2007-12-04_09:40-edward.lee@engineering.uiuc.edu-chunk10dlmgr/
OS: Mac OS X → All
Hardware: PC → All
Whiteboard: [has patch in 392097]
I can corroborate Jesse's findings; the 11th build is still slow, but doesn't appear to clobber the UI thread (does that still run on |main()|?); with recent trunk builds, and my downloads.sqlite file (https://bugzilla.mozilla.org/attachment.cgi?id=292568) it takes quite a bit of time, and on its first opening attempt we beach-ball for over 6 seconds (on my machine, at least) before even showing any portion of the DM window at all.

I'll try the tryserver builds tomorrow with this downloads.sqlite file and get some wall-clock timings for us.  
(Assignee)

Comment 12

10 years ago
If you want a build to try..

https://build.mozilla.org/tryserver-builds/2007-12-07_09:42-edward.lee@engineering.uiuc.edu-beta2.awbar.dlmgr/
Not scientific by any means, but I tested each build:

Today's 2007-12-13-19 vs. Mardak's build in comment 12, above, with the following scenarios:

1) Invoke Tools | Downloads right after an identical Firefox start (same profile, obviously)
2) Took note of the "first-open" time
3) Invoked Tools |Download 9 successive times, taking note of each time

* Results:

Build | First-open time | Successive Open Average (9 opens)
-----------------------------------------------------------
Trunk |     ~16 sec     |            ~14-15 sec           |
Mardak|      ~2 sec     |               ~16 sec*          |
-----------------------------------------------------------

* Even though the TOTAL average time to _fully_ load and render the Download Manager UI takes this long, it's -far- more usable than the current, non-patched trunk builds; here, one can scroll at 3 or 4-second intervals (when whatever's grinding the UI thread decides to give CPU cycles back to the DM window); on the trunk, we block the UI thread completely--spinning beach ball and all--for the ~16-second duration.

(Do we want my downloads.sqlite posted here?)

(In reply to comment #13)

System spec: Mac OS X 10.4, MacBook Pro, 2.2 GHz Intel Core Duo, with 2 GB of RAM.  I'll try to find time to test Windows tomorrow; do we want XP or Vista, or both?
(Assignee)

Comment 15

10 years ago
I'm kinda surprised at the first-open time. Do you mean first opening when first starting Firefox? My iBook G4 1.33GHz PowerPC shows the download manager window with 1 download in less than ~.5 sec even when compiling trunk at the same time.

There's 3 interesting times:
1) First open of dlmgr after starting firefox (how long until the window appears)
2) Non-first opening of dlmgr (how long until the window appears)
3) Finished loading all items (how long until the window stops adding stuff)

Most important time is #2 as #1 will be dealt with in another bug and #3 isn't really the common use case.
Sigh; my table is way misleading; sorry about that.

For Mardak's builds, the time should be represented as such:

Total time to open the DM window and finish rendering is around ~16-17 seconds; of those, it takes us--again on average--2 seconds to open the DM window, which leaves 14-15 seconds to completely finish populating (I take the time it takes to completely finish setting the relative vertical size of the scrollbar, as the indication of time-to-render the DM lists).

This means that the overall net time to completely finish opening the DM is around 16 seconds on both builds; the perception and user experience is much-improved in Mardak's build, however we still have a larger performance issue at stake.
Created attachment 293110 [details]
downloads.sqlite with 175 entries
Created attachment 293132 [details]
downloads.sqlite with 277 entries

Just because I can, here's one with 277 entries.  This one has been through a lot (basically since we first landed the new DM).
So - we can improve UI performance by adding more delay to our setTimeout call I'd think.  Perhaps we should play around with this?
(Assignee)

Updated

10 years ago
Depends on: 399838
(Assignee)

Comment 20

10 years ago
Both bug 392097 and bug 399838 are fixed, so the time for the download manager to show up when pressing ctrl-j or starting a download with auto-open should be really fast.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [has patch in 392097]
Target Milestone: Firefox 3 M10 → Firefox 3 M11
I spun-off bug 408745; I hope to get a chance to verify this bug in a bit.
Keywords: qawanted
I'm going to claim victory on this particular bug, as it's now nearly instantaneous to actually *open* the Download Manager window on trunk; building the list is a different story, but is still much-improved due to the way we chunk its populating.

I think we could and should still do some caching, such that subsequent DM-window opens are faster, but that'll be a separate bug.

Verified FIXED using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008010204 Minefield/3.0b3pre
Status: RESOLVED → VERIFIED
(In reply to comment #22)

> I think we could and should still do some caching, such that subsequent
> DM-window opens are faster, but that'll be a separate bug.

I filed bug 410538.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.