Bugzilla – Bug 2149
Audacity consumes large amounts of CPU time
Last modified: 2019-10-31 05:52:22 UTC
Testing on W10 with audacity-2.3.3-alpha-280-6adb2abc98618ffaee43841bf229ec5b14e40ed6 At step 4 with an empty Audacity project, idling doing nothing, the CPU usage on my SSD HP Envy is 34% This is a huge increase over 2.3.2 and all earlier Audacities which c-nsume 0.0 to 0.1% CPU in the same state. Reported on other platforms too (Audacity state unknown): a) David Bailes (initial reporter) reports 25% CPU usage b) Steve: >I see this on Linux too. >With the current build, Audacity uses 10% of total CPU on an >8 core machine (80% of one core) when idle. >In comparison, Audacity 2.2.1 uses less than 1% of total CPU. c) Cliff: >Also on MacOS. Build this morning, 51% of one CPU and on 2.3.2 it is only 3%.
Paul reported >The culprits are ScrubbingToolBar, if that is shown, and the ruler panel. >I have fixed the excessive idle time consumption of the scrubbing toolbar. >I will work on the ruler. And later Paul wrote by email: >Strange, on my MacBook, Activity Monitor tells me that the idle CPU >consumption of Audacity 2.3.2 is all of 4.0% give or take a few tenths. > >But surely 2.3.3 should be not much worse whichever the platform, >and I think that will be so after my recent commit >274331cc267008f7c49aea771274814f5d79ebdd > >It may be a very little bit worse, because I decided to move some more UI >updates into idle time, a price to pay for better decoupling in the source code. Cliff responded: >On My macbook Pro, MacOS 10.13.6 it now runs idle at 6.7 - 6.9%. >Great improvement, but still 50% more than 2.3.2.
Testing on 64-bit Linux: Commit 274331cc267008 is an improvement from immediately before, but CPU usage while idle is still MUCH higher than in previous Audacity releases.
Mostly fixed by commit bff30b6ae996f44d891c624d126336759b34082f and some preceding ones. On my MacBook, CPU consumption is about 4.7% at that commit, compared with about 4.3% for version 2.3.2.
Testing on W10 with Steve's Appveyor build audacity-2.3.3-alpha-282-7857769f96fa8bd6d9954ba5b59bf95dee0b93ec This looks to be fixed OK for Windows. With particular reference to my testing in Comment #0 the CPU consumption for 2.3.3 alpha at idle shows as 0% - just the same as 2.3.2 CPU percentage consumption 2.3.3 2.3.2 launch 9 8 idle 0 0 generate 31 30 amplify 22 19 save 30 33 export 33 33 open 9 12
Next week I will be in Zurich and can test on my older slower W10 laptop there
The most recent commits have substantially mitigated this problem, though when the mouse pointer is over the interface, I'm still seeing about 2x increase in CPU load compared to older releases.
(In reply to Steve Daulton from comment #6) Steve wrote >though when the mouse pointer is over the interface, I'm still seeing >about 2x increase in CPU load compared to older releases I do not observe this on Windows W10
MacOS 10.13.6 commit: 3dc421 CPU load is actually less than 2.3.2 here. 2.3.2 - 5.3% 2.3.3 - 4.8% Slight increase in load, 0.2 or 0.3% when Audacity is in the foreground. No noticable difference with mouse pointer over the window.
Testing on Linux with builds made with identical configure options on the same machine. (more precise measurements than my previous tests). Audacity 2.3.3 at commit 7857769f96fa8bd6d9954ba5b59bf95dee0b93ec CPU when idle as % of one CPU core: 2.3.3 alpha: 6.0% to 6.7% 2.3.2: 3.0% to 3.7%
I'd say comment 8 means it's down to measurement error -- I don't believe 2.3.3 is really less. As for comment 9, try commenting out the EVT_IDLE lines to see if it makes a difference, and please report. Commenting out EVT_IDLE would not be acceptable as a fix of course, because that may have unacceptable effects on the display.
Measurements were made in exactly the same say as before and multiple times with both versions and the numbers were consistent every time. I was surprised myself so don't can't explain the lower percentage.
(In reply to Paul L from comment #10) Paul wrote: > try commenting out the EVT_IDLE lines to see if it makes a difference When commenting out all EVT_IDLE lines, I see lower CPU usage when Audacity is running in the background, but no significant improvement when the Audacity window is on top. I've also noticed that CPU goes up considerably when selecting audio (up to 40% while dragging across the waveform), and around 35% to 40% while scrubbing. During scrubbing, the green play cursor triangle leaves a black trail on the Time Line. (I'll attach a screenshot).
Created attachment 835 [details] black trail on Time Line when scrubbing
(In reply to Steve Daulton from comment #13) I confirm I see the same black line when scrubbing on W10 with audacity-2.3.3-alpha-282-7857769f96fa8bd6d9954ba5b59bf95dee0b93ec
(In reply to Steve Daulton from comment #12) >I've also noticed that CPU goes up considerably when selecting audio >(up to 40% while dragging across the waveform), >and around 35% to 40% while scrubbing. on W10 I only se a maximum of 3% while scrubbing - but on dragging across the wavform for selection the maximum is around 15% which seems somewhat high - but these figures are in line with waht I observe for 2.3.2 - so mo change really on W10
On my Mac MacOS 10.13.6 I see: - Scrubbing - no black line like has been reported on other systems. - scrubbing puts CPU up to 89% - Dragging to select - CPU as high as 102%
(In reply to Cliff Scott from comment #16) Cliff, but how do those numbers for 2.3.3 alpha compare with 2.3.2 (on W10 I see little or no difference) ?
Using Audacity 2.3.2 I see: - No black line - Scrubbing 87% compared to 89% on 2.3.3 - Drag to select 82% compared to 102% on 2.3.3
I have logged the black line as new P2 Bug #2151 >Scrubbing/seeking corrupts the Timeline with black line/black tick marks as this is a separate issue from the CPU consumption
I found some time to do some preliminary timing tests, as I was concerned that CPU consumption changes may also affect processing times. Tests based on: https://wiki.audacityteam.org/wiki/Testing:_timing_tests I only did a single pass (not the triple pass) at this preliminary stage. I'm glad to be able to report that I observe no major changes in timings for 2.3.2 and the latest 2.3.3 alpha: audacity-2.3.3-alpha-282-7857769f96fa8bd6d9954ba5b59bf95dee0b93ec I will do more thorough retests when we eventually get an RC
CPU while scrubbing is about the same in Audacity 2.3.2 and 2.3.3 (about 30%). CPU while selecting with one audio track is higher in Audacity 2.3.3 (around 40% to 45%) than in Audacity 2.3.2 (around 25% to 30%). Interestingly, with multiple audio tracks, CPU when selecting in Audacity 2.3.2 increases noticeably up to around 40% to 45%, whereas in Audacity 2.3.3 there is little or no increase (remaining at around 40% to 45%). I'm surprised that CPU is so high when selecting, but it is only a little worse in 2.3.3 than in 2.3.2 with one audio track, and no worse with multiple audio tracks. When idle, Audacity 2.3.3 uses roughly double CPU compared to 2.3.2 (6% to 8% compared with 3% to 4%).
Downgrading to P2 - but leaving open for now following a QA discussion with Steve. It can then be an RM decision at Release time whether or not it is deemed gooid enough then.. ----------------------------------------------- We are still a bit concerned by the increase in CPU while idle, though MUCH less concerned than before Paul's recent fixes for this problem. The danger that we see is a creeping increase in system requirements, which eventually forces users to either, a) use old versions of the software, b) switch to alternative software, c) send their PC to landfill and buy a more powerful machine (if they can afford to do so). We think that the problem has been sufficiently mitigated for the 2.3.3 release. But as soon as this bug is closed, that's the end of any further mitigation efforts. And that is why we're keeping this bug open until we're well into the RC stage, in the hope that further improvements may be made.
8% when idle is almost certainly OK, as it is probably much less than 8% if some other compute intensive app is busy. If Audacity were taking 10% of CPU time doing nothing, even when some other compute intensive app is busy, then that would be a cause for concern. So '6% to 8% when idle' as a problem is more about the optics than about the actual effect on users.
Testing on W10 (8GB RAM 2.7GHz and SSD) with audacity-2.3.3-alpha-283-beb378f61ac971dc7b493442d6a282ad3fb5b785 of 11Jul19 At idle I see mostly 0% shown with an occasional foray up to 0.2% For Click&Drag Select I see 6-7% CPU ============================================ Testing on macOS 10.14.5 (8GB RAM 2.7 GHz and SSD) with 2.3.3 alpha jc003 of 11Jul19 At idle I see 5.7%-6.4% - settling at 6.3% For Click&Drag Select I see 14-30% CPU ============================================ So with very similar processor configs the Mac CPU consumption looks to be 5 times that od W10
I found on the Mac that I needed to drag slowly enough that Activity Monitor can stabilize because it only updates every few seconds so the early readings can be very inaccurate. I suspect Windows method of measuring CPU load are different so comparing the two may not be possible. The key is to see the difference between 2.3.2 and 2.3.3.
Testing on W10 with audacity-2.3.3-alpha-283-beb378f61ac971dc7b493442d6a282ad3fb5b785 Testing in Zurich on my older slower spinning metal disk PC - this looks to be fixed for Windows. I see almost identical figures for CPU usage for 2.3.2 and tha latest 2.3.3 alpha a) 0.0-0.4% at idle b) up to 10% for click&drag select Looks fine to me for W10
Testing on W10 with audacity-2.3.3-alpha-296-13348841c038bdd7614ae9e401ad0a419f7fb44a on my older slower less powerful Toshiba Satellite laptop with spinning metal disk in Zurich. I observe very similar figures for CPU consumption on 2.3.3 alpha and 2.3.2 Idle: normally at 0% (occasionally maxing to 0.5%) Click&Drag Select: maxing at around 8%
Testing with 2.3.3 RC01 1) On W10 - when Audacity is idle I observe 0% CPU in the Task Manager 2) on macOS 10.15 - with Audacity idle it shows 4.5% CPU - this is the same as for 2.3.2 and 2.3.1 (I cannot now run earlier versions as they are 32-bit). This is higher than the figure that testing under Mojave gave - but still acceptable abd consistent across the 64-bit versions. Click&drag select on both platforms does not produce an unduly heavy load a) W10 7-12% b) Mojave 14-20% These figures remain significantly lower than reported in the original report in Comment #1 Accordingly I am closing this bug as QUICKFIXED
