Re: [Audacity-devel] Massive slow down of Nyquist effects when label track present
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Paul L. <pau...@gm...> - 2017-01-15 02:40:03
|
I made changes so that just enough status flag updating is done for my purposes, not all of it, when checkUpdate is true, and then the Mac Window menu works as intended. See branch slow-nyquist-and-labels in my fork, and this commit; please do git commit --am to edit the comment to make the description more complete. ffccd99ffd23758bc31f58f506bcc8628564d21c PRL On Sat, Jan 14, 2017 at 2:17 PM, Steve the Fiddle <ste...@gm...> wrote: > I've discovered why the slowdown is occurring: > > When Nyquist effects run, ProgressDialog::Update is called on every > callback which can be around 3000 times per second when Nyquist is > running flat out. > > In ProgressDialog::Update YieldFor is called each time, which is > excessive, but this is not the root of the problem and does not > explain why there is a MUCH greater slowdown when a label track is > present. > > We "should" reduce the calls to YieldFor to a more reasonable rate, > and this gives a significant improvement to the performance of Nyquist > effects irrespective of the label track problem. The easy,way to do > this is to only call YieldFor if a reasonable amount of time has > passed since the previous call, say 50 ms. We already have the "now" > time within Update, so there's virtually no overhead in fixing it this > way. > > The big slowdown when a label track is present is due to > wxTheClipboard->IsSupported(wxDF_TEXT); > in LabelTrack::IsTextClipSupported() > > This is called each time we update the flags in Menus.cpp > > The specific flag is "TextClipFlag", which as far as I can see is unused. > > In https://github.com/audacity/audacity/commit/617fdb387f > the test: > > if (checkActive && !IsActive()) > return; > > was commented out, so now we continue to update the flags even while > effects are processing. > I don't know the reason for this change, it appears to be unrelated to > the Mac specific changes in the rest of this commit. > > So, in short, we are updating the flags many times per second during > processing, and if a label track is present, then this includes the > (slow) update of "TextClipFlag" (which appears to be unused). > > My question is, why does commit 617fdb387f comment out the test: > if (checkActive && !IsActive()) > > Steve > > On 13 January 2017 at 12:23, Steve the Fiddle <ste...@gm...> > wrote: > > The big slowdown in Nyquist when a label track is present seems to be > > a recent problem. I'll continue investigating. > > > > Steve > > > > On 12 January 2017 at 18:22, Steve the Fiddle <ste...@gm...> > wrote: > >> The "double speed" is versus the speed in 2.1.3 alpha without the > >> presence of label tracks. > >> I've not tested it against 2.1.2 yet but shall do so. > >> > >> As Roger indicated, there are a couple of ways to fix this. Putting > >> the YieldFor call on a timer is the simple solution and the solution > >> that I've tested (only on Linux so far). > >> > >> The problem does not occur (is not noticeable) with built-in effects > >> because they call Update far less frequently (their calls to Update > >> appear to already be on a timer somewhere). I've not tested other > >> plug-in types, but if the same problem exists there too, then the > >> proposed fix should work for all plug-in types. > >> > >> On 12 January 2017 at 17:48, James Crook <cr...@in...> wrote: > >>> Gale wrote: > >>>> Is this a safe and simple fix? I might call the bug P1 unless James > strongly > >>>> opposes it, given it's a bad regression on 2.1.2 and we have two > outstanding > >>>> P1s still to fix. At the start of a release I would rate this as P1, > >>>> because no reason to do otherwise. > >>> Whether you call it P1 or P2, RM approves the fix as described. > >>> > >>> I also think it is of (P2) importance that we understand why the > >>> existence of a label track made a difference. Otherwise the 'same' > >>> issue could bite us in other ways. For example if ALL progress dialogs > >>> now run slower when we have a label track, we'd want to know. > >> > >> I agree, but that problem is hard to see (hidden) when we call > >> YieldFor less often. > >> > >> As it's a regression, perhaps working through a load of previous > >> builds to narrow down when the problem appeared may help to locate > >> what's causing it. (It's not practical for me to attempt git bisect > >> without narrowing it down first because it takes too long to build on > >> my machine.) > >> > >> Steve > >> > >>> > >>> --James. > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |