902733 - Download button in toolbar causes high CPU usage during downloads

Status: RESOLVED INCOMPLETE

(Firefox :: Downloads Panel, defect)

Description

[Nikolay Martynov]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20130726 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130726060637

Steps to reproduce:

I've tried to download kernel packages from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.5-saucy/

Here's the link to profile information: http://people.mozilla.com/~bgirard/cleopatra/#report=6812667affc3fa8ff69bf2ef0678380879cd0bfa



Actual results:

The FF UI became very unresponsive - even for pop up menu it took seconds to highlight element to which cursor was pointing


Expected results:

There should be no noticeable additional CPU load caused by downloads.

Please let me know if any more information is required.
Thanks!

Comment 1

[Loic]

Could you test with a clean profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Nikolay Martynov]

I've tried with clean profile. It wasn't that bad, but still - downloading file consumed ~15% of CPU (according to top, core2duo laptop). When nothing is being downloaded in clean profile CPU consumption is negligible.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Nikolay Martynov from comment #2)
> I've tried with clean profile. It wasn't that bad, but still - downloading
> file consumed ~15% of CPU (according to top, core2duo laptop). When nothing
> is being downloaded in clean profile CPU consumption is negligible.

Nikolay, do you still see this when using Firefox 30?  (or 31 due in the next couple weeks)

Comment 4

[Nikolay Martynov]

I've just retried with stock firefox from Ubuntu 14.04 (30) and firefox-trunk. In both cases downloading file causes significant cpu spike. On firefox 30, on clean profile top shows ~25% of cpu load during file download (i7-3520M). Without file download firefox with clean profile consumes <5% cpu.

So, unfortunately problem still persists in both stable and trunk firefoxes.

Comment 5

[Brian Marshall]

Profile taken with mozilla-central build: http://people.mozilla.org/~bgirard/cleopatra/#report=bbcccd727db30e46ecbf4aefdea744b387b38e08

It seems that a lot of time is spent in Promise code, which is used by DLT_onProgressChange64() @ DownloadLegacy.js:186. Specifically, Promise() @ Promise-backend.js:305 and PromiseWalker.scheduleWalkerLoop() @ Promise-backend.js:688. Unfortunately the self time for those are 0, but the calls inside those functions don't seem to account for the running time.

Comment 6

[Mike]

Same with Firefox 33 on Ubuntu 12.04 64 bit

Comment 7

[Kai-Uwe Rommel]

I also see the problem of high CPU usage when downloading some large files with sufficient download rate (e.g. 1 MByte/sec or higher) - always, reproducible and on each and every Firefox installation that I use (all on Windows).

For example, I just downloaded both a RHEL and a CentOS ISO image at the same time. Combined both downloads had a throughput of about 6...8 MByte/sec. Firefox' CPU usage went to 70% on a VM using two Xeon server cores. When one download finished and I unpacked that ISO with 7Zip, the 7Z process used almost NO CPU at all while Firefox still used more than 50%.

So, something is really programmed in a bad way in the Firefox download code. I am seeing this, as I already wrote, on many installations and always and since so many years of using Firefox that I am very astonished that it should not be reproducible by the developers so that it could be fixed quickly.

Comment 10

[Karl Tomlinson (:karlt)]

CPU use continues even with all windows minimized.

Removing the download button reduces cpu use by 80%.

perf top on the main thread indicates style resolution, so a key question, I think, is: what is forcing style re-resolution even on minimized windows?

 2.99%  firefox     arena_dalloc                                          
 2.76%  firefox     arena_malloc                                          
 2.13%  libxul.so   PLDHashTable::SearchTable<(PLDHashTable::SearchReason)
 1.82%  libxul.so   nsStyleContext::DoGetStyleDisplay<true>               
 1.79%  firefox     arena_run_tree_remove                                 
 1.55%  firefox     arena_run_tree_insert                                 
 1.34%  firefox     arena_run_tree_search                                 
 1.17%  libpthread- pthread_mutex_lock                                    
 1.11%  libxul.so   nsIFrame::BuildDisplayListForChild                    
 1.05%  libxul.so   TraversalTracer::onChild                              
 1.03%  libxul.so   PLDHashTable::SearchTable<(PLDHashTable::SearchReason)
 0.84%  libpthread- __pthread_mutex_unlock_usercnt                        
 0.57%  libxul.so   mozilla::gfx::BaseRect<int, nsRect, nsPoint, nsSize, n
 0.53%  libxul.so   mozilla::CommonAnimationManager::GetAnimationCollectio
 0.48%  libxul.so   mozilla::gfx::Matrix4x4::operator*<float>             
 0.47%  libxul.so   mozilla::ContainerState::ProcessDisplayItems          
 0.47%  libxul.so   nsDisplayListBuilder::IsAnimatedGeometryRoot          
 0.47%  libxul.so   PLDHashTable::FindFreeEntry                           
 0.45%  libxul.so   PLDHashTable::MoveEntryStub                           
 0.44%  libxul.so   nsIFrame::Properties                                  
 0.42%  firefox     mozilla::HashBytes                                    
 0.42%  libxul.so   PLDHashTable::Iterator::Next                          
 0.40%  libxul.so   PLDHashTable::Search                                  
 0.39%  libxul.so   nsStyleContext::DoGetStyleBorder<true>                
 0.39%  libxul.so   PLDHashTable::Add

Comment 11

[Marco Bonardo [:mak]]

this remembers me of bug 848792...
Probably we should update the progress indicator less often.

But also figuring out why we update style with a minimized window :(

Comment 12

[Matt Cosentino]

I still get high CPU usage after removing the button from the toolbar, so there must be more to it.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

I see extra 15% CPU usage during download which comes from SHA256_Compress(). Is it possible that the downloaded data goes through IPC bridge which is encrypted by nss/SHA256_Compress()? The backtrace and perf indicates that.

Comment 14

[marnix]

I'm seeing this behavior in Firefox 54 on macOS Sierra, high cpu usage, laggy ui response and the download button seems to alternate every second between 0% and the actual progress.

When I remove the button from the toolbar, cpu usage decreases a bit and responsiveness returns to normal.

Comment 15

[marnix]

This bug now seems to be fixed in the latest Nightly (56). Probably has something to do with the new GUI. Awesome!

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to marnix from comment #15)
> This bug now seems to be fixed in the latest Nightly (56). Probably has
> something to do with the new GUI. Awesome!

Nikolay, do you agree?

Comment 17

[Nikolay Martynov]

I'm sorry, I do not run nightly builds at the moment. I'll update this story once I have a chance to install and try it. Thanks!