Summary: Download Manager should cache its "Downloads"-window list
Currently, even with improvements in the way we build the Download Manager list--see bug 408745 and bug 404006--we still don't cache that list; this means that subsequent Download Manager window invocations will take just as long to populate as their previous ones.
Not blocking, far too late for changes of this type.
When the file list in Downloads is long, users wait up to a few seconds before a new download is performed.
Waiting two extra seconds for a download is usually not a problem.
However, increasingly people are using Web-pages to control
interactive animations like in Bio-molecule graphics.
Clicking a Web link results in a certain action in the Software that
is controlled by the Web-page.
In this case 2 seconds delay for each user interaction is certainly
not acceptable. The delay vanishes after clearing list. To my
opinion, this performance bug is important.
For examples see page
The protein viewer Vmd already has the possibility to be controlled by
Web-links of the form http://localhost
The authors of another protein viewer Pymol currently implementing this feature:
"Also, we're in the process of adding web-service interface to
PyMOL as well, so you will soon simply be able message PyMOL with
are URL request like:
Therefore it would be helpful if the delay of the downloads manager could be improved.
Shawn, anything we can do to improve the time needed to enqueue a new download?
I'm not seeing this delay myself, nor do I see code that would cause it (short of network latency)
Christoph, could you attach a prepared downloads.sqlite file which shows this behavior? It's sometimes easier to have a testcase to confirm the behavior. Thanks.
(In reply to comment #6)
> Christoph, could you attach a prepared downloads.sqlite file which shows this
> behavior? It's sometimes easier to have a testcase to confirm the behavior.
Christoph appears to be gone