We still need to work on performance improvements
Some recent work that is about to land http://firstname.lastname@example.org/ Alice, willing to test this and report improvements?
On my system, my profile (550 downloads) opens instantly, Alice's test profile (4500 downloads) takes 2 seconds. Measured from clicking "Show all downloads" from the downloads button.
out of 1650ms, that is the total time spent in invalidateContainer, 1235 are due to appendChild, 373 are spent in AddDownloadData (88 self, 274 in creating DownloadElementShell), 42 in nsStyleSet::FileRules
As Mano pointed out today, we are spending some time in getDownloadState on placesNode() setter, that must be investigated, most of this time goes into _getAnnotation, but that should just do a Map lookup, a Map set and return a value. Maybe the Map is a perf hog?
(In reply to Marco Bonardo [:mak] from comment #1) > Some recent work that is about to land > http://email@example.com- > 02e43b34326c/ > > Alice, willing to test this and report improvements? 1. It takes about 3 sec to render download view after Download clicked in Library. 2. It takes about 1 sec to shutdown Browser, Bug 825242 3. No more freeze browser when open link 825242, Bug 827268 Everything improved.
(In reply to Alice0775 White from comment #5) > Everything improved. Thanks, glad we are moving the right direction.
Remeasured with bug 828111, the time on my system is about 300ms and we also have plans to reduce it further (reducing annos from 3 to 2). I think we are almost done here.
Fixed by dependencies. The most offending hangs should be gone, there is still bug 824260 that may improve window close times and bug 826991 that may bring a small gain, though there's no reason to keep this open to track single small improvements.