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!
Could you test with a clean profile, please. https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
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.
(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)
Whiteboard: [closeme 2014-08-15]
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.
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.
Same with Firefox 33 on Ubuntu 12.04 64 bit
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Summary: Downloads cause high CPU usage → Download button in toolbar causes high CPU usage during downloads
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 :(
I still get high CPU usage after removing the button from the toolbar, so there must be more to it.
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.
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.
This bug now seems to be fixed in the latest Nightly (56). Probably has something to do with the new GUI. Awesome!
(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?
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!
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.