Quantcast

Massive slow down of Nyquist effects when label track present

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Massive slow down of Nyquist effects when label track present

Stevethefiddle
On Linux, Nyquist effects may run (crawl) as much as 20 times slower
if one or more label tracks are present.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1575

I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
(around line 1265). Even in the absence of label tracks, this YieldFor
slows down Nyquist execution significantly, but the slow down becomes
extreme if label tracks are present

The problem can be mitigated by calling YieldFor less frequently, but
that does not address the question of why the presence of a label
track causes such a huge slow down in YieldFor. Any ideas?

Steve

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
rbd
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

rbd

That's really interesting. I don't know what's going on, but here are some thoughts...

I found this in some wxPython docs after a quick search: "Yields control to pending messages in the windowing system. This can be useful, for example, when a time-consuming process writes to a text window. Without an occasional yield, the text window will not be updated properly, and on systems with cooperative multitasking, such as Windows 3.1 other processes will not respond."

Even when "compute bound", Nyquist DSP and Xlisp interpreter call out occasionally to poll for events like typing the break character or incoming Open Sound Control messages.

So I imagine that this polling is directed by Audacity to YieldFor in order to let wxWidgets update the progress bar. One would hope you could update the progress bar about 10-50 times per second, and that that would take a small fraction of CPU time, the rest going to Nyquist.

I suppose YieldFor is getting called excessively often or takes excessive amounts of CPU time. Figuring out which is the case (or both) would be the next step.

I hope this is helpful or at least supports what you've already guessed. Sorry I don't know any real answers.

-Roger

On 1/11/17 9:40 AM, Steve the Fiddle wrote:
On Linux, Nyquist effects may run (crawl) as much as 20 times slower
if one or more label tracks are present.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1575

I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
(around line 1265). Even in the absence of label tracks, this YieldFor
slows down Nyquist execution significantly, but the slow down becomes
extreme if label tracks are present

The problem can be mitigated by calling YieldFor less frequently, but
that does not address the question of why the presence of a label
track causes such a huge slow down in YieldFor. Any ideas?

Steve

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
Thanks for the response Roger. Comments in-line below.

On 11 January 2017 at 17:27, Roger Dannenberg <[hidden email]> wrote:

> That's really interesting. I don't know what's going on, but here are some
> thoughts...
>
> I found this in some wxPython docs after a quick search: "Yields control to
> pending messages in the windowing system. This can be useful, for example,
> when a time-consuming process writes to a text window. Without an occasional
> yield, the text window will not be updated properly, and on systems with
> cooperative multitasking, such as Windows 3.1 other processes will not
> respond."
>
> Even when "compute bound", Nyquist DSP and Xlisp interpreter call out
> occasionally to poll for events like typing the break character or incoming
> Open Sound Control messages.
>
> So I imagine that this polling is directed by Audacity to YieldFor in order
> to let wxWidgets update the progress bar.

Also to allow effects to respond to "Cancel".

> One would hope you could update
> the progress bar about 10-50 times per second, and that that would take a
> small fraction of CPU time, the rest going to Nyquist.
>
> I suppose YieldFor is getting called excessively often or takes excessive
> amounts of CPU time. Figuring out which is the case (or both) would be the
> next step.

It seems to be both.

When there is no label track, on my (Debian) machine, YieldFor is
called around 3000 times per second, which is clearly excessive.
When there is a label track, running an effect such as the High Pass
filter (no LISP looping, just crunching numbers in the C code), calls
to YieldFor drop to around 130 per second because YieldFor is taking
so long.

YiedFor is called on every loop through ProgressDialog::Update

Example:
Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.

No label track:
Time taken = 22 seconds
Number of call to YieldFor = 70381

With label track:
Time taken = 555 seconds
Number of calls to YieldFor = 72670


With YieldFor commented out:

No Label track:
Time taken = 8 seconds
Count through Update = about 76000

With Label track:
Time taken = 8 seconds
Count through Update = about 76000

So Yield for is creating a significant slow down even without a label
track, but we really shouldn't be calling it 3000 times per second,
but the thing that is puzzling me is why the slow down becomes
catastrophic when a label track is present.

Steve


>
> I hope this is helpful or at least supports what you've already guessed.
> Sorry I don't know any real answers.
>
> -Roger
>
> On 1/11/17 9:40 AM, Steve the Fiddle wrote:
>
> On Linux, Nyquist effects may run (crawl) as much as 20 times slower
> if one or more label tracks are present.
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1575
>
> I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
> (around line 1265). Even in the absence of label tracks, this YieldFor
> slows down Nyquist execution significantly, but the slow down becomes
> extreme if label tracks are present
>
> The problem can be mitigated by calling YieldFor less frequently, but
> that does not address the question of why the presence of a label
> track causes such a huge slow down in YieldFor. Any ideas?
>
> Steve
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
rbd
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

rbd

More below...


On 1/11/17 2:10 PM, Steve the Fiddle wrote:
Thanks for the response Roger. Comments in-line below.

On 11 January 2017 at 17:27, Roger Dannenberg [hidden email] wrote:
That's really interesting. I don't know what's going on, but here are some
thoughts...

I found this in some wxPython docs after a quick search: "Yields control to
pending messages in the windowing system. This can be useful, for example,
when a time-consuming process writes to a text window. Without an occasional
yield, the text window will not be updated properly, and on systems with
cooperative multitasking, such as Windows 3.1 other processes will not
respond."

Even when "compute bound", Nyquist DSP and Xlisp interpreter call out
occasionally to poll for events like typing the break character or incoming
Open Sound Control messages.

So I imagine that this polling is directed by Audacity to YieldFor in order
to let wxWidgets update the progress bar.
Also to allow effects to respond to "Cancel".

One would hope you could update
the progress bar about 10-50 times per second, and that that would take a
small fraction of CPU time, the rest going to Nyquist.

I suppose YieldFor is getting called excessively often or takes excessive
amounts of CPU time. Figuring out which is the case (or both) would be the
next step.
It seems to be both.

When there is no label track, on my (Debian) machine, YieldFor is
called around 3000 times per second, which is clearly excessive.
When there is a label track, running an effect such as the High Pass
filter (no LISP looping, just crunching numbers in the C code), calls
to YieldFor drop to around 130 per second because YieldFor is taking
so long.
Maybe if things were adjusted for callbacks at a reasonable rate at real-time playback speed, and if callbacks are paced by audio buffer computation, then running flat out, you could be going 50x real time and 3000 would not be an unlikely polling rate. I think given the wide range in sample rates from simple compute bound filters to real-time (in Nyquist outside of Audacity), the right thing to do is probably either adaptive (return immediately from N-1 out of N callbacks, adjusting N to keep a sane rate), OR check the time at every callback and do work (like YieldFor) every 10ms or so. The latter is approach is simplest, but I'm not sure what it costs to read the current time on Windows, and we don't want that to become the bottleneck.


YiedFor is called on every loop through ProgressDialog::Update

Example:
Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.

No label track:
Time taken = 22 seconds
Number of call to YieldFor = 70381

With label track:
Time taken = 555 seconds
Number of calls to YieldFor = 72670


With YieldFor commented out:

No Label track:
Time taken = 8 seconds
Count through Update = about 76000

With Label track:
Time taken = 8 seconds
Count through Update = about 76000

So Yield for is creating a significant slow down even without a label
track, but we really shouldn't be calling it 3000 times per second,
but the thing that is puzzling me is why the slow down becomes
catastrophic when a label track is present.
Yes, that's puzzling. I can't even venture a guess on that one.

Steve


I hope this is helpful or at least supports what you've already guessed.
Sorry I don't know any real answers.

-Roger

On 1/11/17 9:40 AM, Steve the Fiddle wrote:

On Linux, Nyquist effects may run (crawl) as much as 20 times slower
if one or more label tracks are present.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1575

I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
(around line 1265). Even in the absence of label tracks, this YieldFor
slows down Nyquist execution significantly, but the slow down becomes
extreme if label tracks are present

The problem can be mitigated by calling YieldFor less frequently, but
that does not address the question of why the presence of a label
track causes such a huge slow down in YieldFor. Any ideas?

Steve

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
On 11 January 2017 at 22:13, Roger Dannenberg <[hidden email]> wrote:

> More below...
>
>
> On 1/11/17 2:10 PM, Steve the Fiddle wrote:
>
> Thanks for the response Roger. Comments in-line below.
>
> On 11 January 2017 at 17:27, Roger Dannenberg <[hidden email]> wrote:
>
> That's really interesting. I don't know what's going on, but here are some
> thoughts...
>
> I found this in some wxPython docs after a quick search: "Yields control to
> pending messages in the windowing system. This can be useful, for example,
> when a time-consuming process writes to a text window. Without an occasional
> yield, the text window will not be updated properly, and on systems with
> cooperative multitasking, such as Windows 3.1 other processes will not
> respond."
>
> Even when "compute bound", Nyquist DSP and Xlisp interpreter call out
> occasionally to poll for events like typing the break character or incoming
> Open Sound Control messages.
>
> So I imagine that this polling is directed by Audacity to YieldFor in order
> to let wxWidgets update the progress bar.
>
> Also to allow effects to respond to "Cancel".
>
> One would hope you could update
> the progress bar about 10-50 times per second, and that that would take a
> small fraction of CPU time, the rest going to Nyquist.
>
> I suppose YieldFor is getting called excessively often or takes excessive
> amounts of CPU time. Figuring out which is the case (or both) would be the
> next step.
>
> It seems to be both.
>
> When there is no label track, on my (Debian) machine, YieldFor is
> called around 3000 times per second, which is clearly excessive.
> When there is a label track, running an effect such as the High Pass
> filter (no LISP looping, just crunching numbers in the C code), calls
> to YieldFor drop to around 130 per second because YieldFor is taking
> so long.
>
> Maybe if things were adjusted for callbacks at a reasonable rate at
> real-time playback speed, and if callbacks are paced by audio buffer
> computation, then running flat out, you could be going 50x real time and
> 3000 would not be an unlikely polling rate. I think given the wide range in
> sample rates from simple compute bound filters to real-time (in Nyquist
> outside of Audacity), the right thing to do is probably either adaptive
> (return immediately from N-1 out of N callbacks, adjusting N to keep a sane
> rate), OR check the time at every callback and do work (like YieldFor) every
> 10ms or so. The latter is approach is simplest, but I'm not sure what it
> costs to read the current time on Windows, and we don't want that to become
> the bottleneck.

Fortunately we already have the current time because we get it earlier
in the same loop (so that we're not updating the progress bar more
than once per second).

Reusing the time, to call YieldFor no sooner than 50 ms after the
previous call, brings performance virtually up to the level I see with
YieldFor disabled, whether a label track is present or not.

In other words, an easy fix that also more than doubles the speed of
many Nyquist effect (on Linux). I don't expect to see such big gains
on other platforms, but there may be a smaller performance boost.

>
>
> YiedFor is called on every loop through ProgressDialog::Update
>
> Example:
> Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
>
> No label track:
> Time taken = 22 seconds
> Number of call to YieldFor = 70381
>
> With label track:
> Time taken = 555 seconds
> Number of calls to YieldFor = 72670
>
>
> With YieldFor commented out:
>
> No Label track:
> Time taken = 8 seconds
> Count through Update = about 76000
>
> With Label track:
> Time taken = 8 seconds
> Count through Update = about 76000
>
> So Yield for is creating a significant slow down even without a label
> track, but we really shouldn't be calling it 3000 times per second,
> but the thing that is puzzling me is why the slow down becomes
> catastrophic when a label track is present.
>
> Yes, that's puzzling. I can't even venture a guess on that one.

It would be good to know as it could be adversely impacting
performance elsewhere.
Anyone have any ideas why this might be?

Steve

>
> Steve
>
>
> I hope this is helpful or at least supports what you've already guessed.
> Sorry I don't know any real answers.
>
> -Roger
>
> On 1/11/17 9:40 AM, Steve the Fiddle wrote:
>
> On Linux, Nyquist effects may run (crawl) as much as 20 times slower
> if one or more label tracks are present.
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1575
>
> I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
> (around line 1265). Even in the absence of label tracks, this YieldFor
> slows down Nyquist execution significantly, but the slow down becomes
> extreme if label tracks are present
>
> The problem can be mitigated by calling YieldFor less frequently, but
> that does not address the question of why the presence of a label
> track causes such a huge slow down in YieldFor. Any ideas?
>
> Steve
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
rbd
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

rbd
Great work, Steve! That's fantastic. Still no ideas on label tracks
though. -Roger


On 1/11/17 5:59 PM, Steve the Fiddle wrote:

> On 11 January 2017 at 22:13, Roger Dannenberg <[hidden email]> wrote:
>> More below...
>>
>>
>> On 1/11/17 2:10 PM, Steve the Fiddle wrote:
>>
>> Thanks for the response Roger. Comments in-line below.
>>
>> On 11 January 2017 at 17:27, Roger Dannenberg <[hidden email]> wrote:
>>
>> That's really interesting. I don't know what's going on, but here are some
>> thoughts...
>>
>> I found this in some wxPython docs after a quick search: "Yields control to
>> pending messages in the windowing system. This can be useful, for example,
>> when a time-consuming process writes to a text window. Without an occasional
>> yield, the text window will not be updated properly, and on systems with
>> cooperative multitasking, such as Windows 3.1 other processes will not
>> respond."
>>
>> Even when "compute bound", Nyquist DSP and Xlisp interpreter call out
>> occasionally to poll for events like typing the break character or incoming
>> Open Sound Control messages.
>>
>> So I imagine that this polling is directed by Audacity to YieldFor in order
>> to let wxWidgets update the progress bar.
>>
>> Also to allow effects to respond to "Cancel".
>>
>> One would hope you could update
>> the progress bar about 10-50 times per second, and that that would take a
>> small fraction of CPU time, the rest going to Nyquist.
>>
>> I suppose YieldFor is getting called excessively often or takes excessive
>> amounts of CPU time. Figuring out which is the case (or both) would be the
>> next step.
>>
>> It seems to be both.
>>
>> When there is no label track, on my (Debian) machine, YieldFor is
>> called around 3000 times per second, which is clearly excessive.
>> When there is a label track, running an effect such as the High Pass
>> filter (no LISP looping, just crunching numbers in the C code), calls
>> to YieldFor drop to around 130 per second because YieldFor is taking
>> so long.
>>
>> Maybe if things were adjusted for callbacks at a reasonable rate at
>> real-time playback speed, and if callbacks are paced by audio buffer
>> computation, then running flat out, you could be going 50x real time and
>> 3000 would not be an unlikely polling rate. I think given the wide range in
>> sample rates from simple compute bound filters to real-time (in Nyquist
>> outside of Audacity), the right thing to do is probably either adaptive
>> (return immediately from N-1 out of N callbacks, adjusting N to keep a sane
>> rate), OR check the time at every callback and do work (like YieldFor) every
>> 10ms or so. The latter is approach is simplest, but I'm not sure what it
>> costs to read the current time on Windows, and we don't want that to become
>> the bottleneck.
> Fortunately we already have the current time because we get it earlier
> in the same loop (so that we're not updating the progress bar more
> than once per second).
>
> Reusing the time, to call YieldFor no sooner than 50 ms after the
> previous call, brings performance virtually up to the level I see with
> YieldFor disabled, whether a label track is present or not.
>
> In other words, an easy fix that also more than doubles the speed of
> many Nyquist effect (on Linux). I don't expect to see such big gains
> on other platforms, but there may be a smaller performance boost.
>
>>
>> YiedFor is called on every loop through ProgressDialog::Update
>>
>> Example:
>> Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
>>
>> No label track:
>> Time taken = 22 seconds
>> Number of call to YieldFor = 70381
>>
>> With label track:
>> Time taken = 555 seconds
>> Number of calls to YieldFor = 72670
>>
>>
>> With YieldFor commented out:
>>
>> No Label track:
>> Time taken = 8 seconds
>> Count through Update = about 76000
>>
>> With Label track:
>> Time taken = 8 seconds
>> Count through Update = about 76000
>>
>> So Yield for is creating a significant slow down even without a label
>> track, but we really shouldn't be calling it 3000 times per second,
>> but the thing that is puzzling me is why the slow down becomes
>> catastrophic when a label track is present.
>>
>> Yes, that's puzzling. I can't even venture a guess on that one.
> It would be good to know as it could be adversely impacting
> performance elsewhere.
> Anyone have any ideas why this might be?
>
> Steve
>
>> Steve
>>
>>
>> I hope this is helpful or at least supports what you've already guessed.
>> Sorry I don't know any real answers.
>>
>> -Roger
>>
>> On 1/11/17 9:40 AM, Steve the Fiddle wrote:
>>
>> On Linux, Nyquist effects may run (crawl) as much as 20 times slower
>> if one or more label tracks are present.
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1575
>>
>> I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
>> (around line 1265). Even in the absence of label tracks, this YieldFor
>> slows down Nyquist execution significantly, but the slow down becomes
>> extreme if label tracks are present
>>
>> The problem can be mitigated by calling YieldFor less frequently, but
>> that does not address the question of why the presence of a label
>> track causes such a huge slow down in YieldFor. Any ideas?
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Gale
Administrator
In reply to this post by Stevethefiddle
Stevethefiddle wrote
On 11 January 2017 at 22:13, Roger Dannenberg <[hidden email]> wrote:
> More below...
>
>
> On 1/11/17 2:10 PM, Steve the Fiddle wrote:
>
> Thanks for the response Roger. Comments in-line below.
>
> On 11 January 2017 at 17:27, Roger Dannenberg <[hidden email]> wrote:
>
> That's really interesting. I don't know what's going on, but here are some
> thoughts...
>
> I found this in some wxPython docs after a quick search: "Yields control to
> pending messages in the windowing system. This can be useful, for example,
> when a time-consuming process writes to a text window. Without an occasional
> yield, the text window will not be updated properly, and on systems with
> cooperative multitasking, such as Windows 3.1 other processes will not
> respond."
>
> Even when "compute bound", Nyquist DSP and Xlisp interpreter call out
> occasionally to poll for events like typing the break character or incoming
> Open Sound Control messages.
>
> So I imagine that this polling is directed by Audacity to YieldFor in order
> to let wxWidgets update the progress bar.
>
> Also to allow effects to respond to "Cancel".
>
> One would hope you could update
> the progress bar about 10-50 times per second, and that that would take a
> small fraction of CPU time, the rest going to Nyquist.
>
> I suppose YieldFor is getting called excessively often or takes excessive
> amounts of CPU time. Figuring out which is the case (or both) would be the
> next step.
>
> It seems to be both.
>
> When there is no label track, on my (Debian) machine, YieldFor is
> called around 3000 times per second, which is clearly excessive.
> When there is a label track, running an effect such as the High Pass
> filter (no LISP looping, just crunching numbers in the C code), calls
> to YieldFor drop to around 130 per second because YieldFor is taking
> so long.
>
> Maybe if things were adjusted for callbacks at a reasonable rate at
> real-time playback speed, and if callbacks are paced by audio buffer
> computation, then running flat out, you could be going 50x real time and
> 3000 would not be an unlikely polling rate. I think given the wide range in
> sample rates from simple compute bound filters to real-time (in Nyquist
> outside of Audacity), the right thing to do is probably either adaptive
> (return immediately from N-1 out of N callbacks, adjusting N to keep a sane
> rate), OR check the time at every callback and do work (like YieldFor) every
> 10ms or so. The latter is approach is simplest, but I'm not sure what it
> costs to read the current time on Windows, and we don't want that to become
> the bottleneck.

Fortunately we already have the current time because we get it earlier
in the same loop (so that we're not updating the progress bar more
than once per second).

Reusing the time, to call YieldFor no sooner than 50 ms after the
previous call, brings performance virtually up to the level I see with
YieldFor disabled, whether a label track is present or not.

In other words, an easy fix that also more than doubles the speed of
many Nyquist effect (on Linux). I don't expect to see such big gains
on other platforms, but there may be a smaller performance boost.
Is that doubled versus the speed we had in 2.1.2 where the label track
was not slowing things down?

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.


Gale  

Stevethefiddle wrote
> YiedFor is called on every loop through ProgressDialog::Update
>
> Example:
> Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
>
> No label track:
> Time taken = 22 seconds
> Number of call to YieldFor = 70381
>
> With label track:
> Time taken = 555 seconds
> Number of calls to YieldFor = 72670
>
>
> With YieldFor commented out:
>
> No Label track:
> Time taken = 8 seconds
> Count through Update = about 76000
>
> With Label track:
> Time taken = 8 seconds
> Count through Update = about 76000
>
> So Yield for is creating a significant slow down even without a label
> track, but we really shouldn't be calling it 3000 times per second,
> but the thing that is puzzling me is why the slow down becomes
> catastrophic when a label track is present.
>
> Yes, that's puzzling. I can't even venture a guess on that one.

It would be good to know as it could be adversely impacting
performance elsewhere.
Anyone have any ideas why this might be?

Steve


> Steve
>
>
> I hope this is helpful or at least supports what you've already guessed.
> Sorry I don't know any real answers.
>
> -Roger
>
> On 1/11/17 9:40 AM, Steve the Fiddle wrote:
>
> On Linux, Nyquist effects may run (crawl) as much as 20 times slower
> if one or more label tracks are present.
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1575
>
> I've traced the problem to the "YieldFor" call in ProgressDialog.cpp
> (around line 1265). Even in the absence of label tracks, this YieldFor
> slows down Nyquist execution significantly, but the slow down becomes
> extreme if label tracks are present
>
> The problem can be mitigated by calling YieldFor less frequently, but
> that does not address the question of why the presence of a label
> track causes such a huge slow down in YieldFor. Any ideas?
>
> Steve
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

James Crook
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.

--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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Paul Licameli


On Sat, Jan 14, 2017 at 2:17 PM, Steve the Fiddle <[hidden email]> 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

I added the Window menu on Macintosh.  When you Minimize the project window, and open the menu again, the Minimize menu item should be disabled.  If you restore those two lines, that does not happen, and the attempt to use the Minimize menu item again causes an error dialog about an operation that can't complete.

I will think about how to get the effect I want without updating all flags.

PRL

 

On 13 January 2017 at 12:23, Steve the Fiddle <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Paul Licameli
In reply to this post by Stevethefiddle
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Paul Licameli
Sorry, I have rebased that commit directly onto master now, without contaminating it with the other experimental fixes for bug 1567.  Please take this commit instead:

cbca44e4990597fb3a429564b96db924e30648c6



On Sat, Jan 14, 2017 at 9:39 PM, Paul Licameli <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Peter Sampson-2
Tested this on 07Jan17 Windows nightly and Mac debug nightly
of 15Jan17.

Testing by generating a 30 minute mono tone and then adding
a track with 100 labels - using Niquist effect High Pass Filter

1)  On W10 there was no differebce between the two runs at c.15 seconds.

2) on Mac with debug build the no label track took 53 seconds
wit the label track this extended to 64 seconds i.e. a 20% increase

Peter.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)

There are now three parts to a full fix for this problem:

1) Reduce the calls to YieldFor to a reasonable rate.
2) Paul's fix for the label track issue.
3) Remove (comment out) the unused updating of TextClipFlag.

Testing on my old dual core Pentium laptop with Debian stable with
these three fixes:
* There is no slowdown of Nyquist (or other) effects when there is a label track
* There is "significant" improvement in the speed of Nyquist effects
whenever the effect takes long enough to show a progress bar.

Performance test:
30 minutes of audio, Silence Finder.

No label track:
Audacity 2.1.2, release build: 18 seconds
Audacity 2.1.3 alpha (not patched): 18 seconds
Patched Audacity 2.1.3 alpha: 6 seconds

With label track:
Audacity 2.1.2 release build: 18 seconds
Audacity 2.1.3 alpha (not patched): 412 seconds
Patched Audacity 2.1.3 alpha: 6 seconds

Question for James (RM), what do you want to do with this? I can send
you a patch for review if that will help.

Steve


On 15 January 2017 at 15:02, Peter Sampson
<[hidden email]> wrote:

> Tested this on 07Jan17 Windows nightly and Mac debug nightly
> of 15Jan17.
>
> Testing by generating a 30 minute mono tone and then adding
> a track with 100 labels - using Niquist effect High Pass Filter
>
> 1)  On W10 there was no differebce between the two runs at c.15 seconds.
>
> 2) on Mac with debug build the no label track took 53 seconds
> wit the label track this extended to 64 seconds i.e. a 20% increase
>
> Peter.
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

James Crook
> Question for James (RM), what do you want to do with this? I can send
> you a patch for review if that will help.

It seems safe from my perspective, even with my hat on.
   18 seconds to 412 is a highly embarrassing regressions.
   18 seconds to 6 seconds is a very worthwhile improvement.

So there is both carrot and stick to get these changes in.  And we're
not 'moments away' from having an RC.

I don't want to commit them from a patch, but if there is a branch ready
to review/merge then I am ready to do so, and it is very likely to go in.

--James (as RM)




On 1/16/2017 11:31 AM, Steve the Fiddle wrote:

> Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
> presume that you have?)
>
> There are now three parts to a full fix for this problem:
>
> 1) Reduce the calls to YieldFor to a reasonable rate.
> 2) Paul's fix for the label track issue.
> 3) Remove (comment out) the unused updating of TextClipFlag.
>
> Testing on my old dual core Pentium laptop with Debian stable with
> these three fixes:
> * There is no slowdown of Nyquist (or other) effects when there is a label track
> * There is "significant" improvement in the speed of Nyquist effects
> whenever the effect takes long enough to show a progress bar.
>
> Performance test:
> 30 minutes of audio, Silence Finder.
>
> No label track:
> Audacity 2.1.2, release build: 18 seconds
> Audacity 2.1.3 alpha (not patched): 18 seconds
> Patched Audacity 2.1.3 alpha: 6 seconds
>
> With label track:
> Audacity 2.1.2 release build: 18 seconds
> Audacity 2.1.3 alpha (not patched): 412 seconds
> Patched Audacity 2.1.3 alpha: 6 seconds
>
> Question for James (RM), what do you want to do with this? I can send
> you a patch for review if that will help.
>
> Steve
>
>
> On 15 January 2017 at 15:02, Peter Sampson
> <[hidden email]> wrote:
>> Tested this on 07Jan17 Windows nightly and Mac debug nightly
>> of 15Jan17.
>>
>> Testing by generating a 30 minute mono tone and then adding
>> a track with 100 labels - using Niquist effect High Pass Filter
>>
>> 1)  On W10 there was no differebce between the two runs at c.15 seconds.
>>
>> 2) on Mac with debug build the no label track took 53 seconds
>> wit the label track this extended to 64 seconds i.e. a 20% increase
>>
>> Peter.
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

Stevethefiddle
On 16 January 2017 at 11:56, James Crook <[hidden email]> wrote:

>> Question for James (RM), what do you want to do with this? I can send
>> you a patch for review if that will help.
>
> It seems safe from my perspective, even with my hat on.
>    18 seconds to 412 is a highly embarrassing regressions.
>    18 seconds to 6 seconds is a very worthwhile improvement.
>
> So there is both carrot and stick to get these changes in.  And we're
> not 'moments away' from having an RC.
>
> I don't want to commit them from a patch, but if there is a branch ready
> to review/merge then I am ready to do so, and it is very likely to go in.

I've made a pull request:
https://github.com/audacity/audacity/pull/178

Steve


>
> --James (as RM)
>
>
>
>
> On 1/16/2017 11:31 AM, Steve the Fiddle wrote:
>> Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
>> presume that you have?)
>>
>> There are now three parts to a full fix for this problem:
>>
>> 1) Reduce the calls to YieldFor to a reasonable rate.
>> 2) Paul's fix for the label track issue.
>> 3) Remove (comment out) the unused updating of TextClipFlag.
>>
>> Testing on my old dual core Pentium laptop with Debian stable with
>> these three fixes:
>> * There is no slowdown of Nyquist (or other) effects when there is a label track
>> * There is "significant" improvement in the speed of Nyquist effects
>> whenever the effect takes long enough to show a progress bar.
>>
>> Performance test:
>> 30 minutes of audio, Silence Finder.
>>
>> No label track:
>> Audacity 2.1.2, release build: 18 seconds
>> Audacity 2.1.3 alpha (not patched): 18 seconds
>> Patched Audacity 2.1.3 alpha: 6 seconds
>>
>> With label track:
>> Audacity 2.1.2 release build: 18 seconds
>> Audacity 2.1.3 alpha (not patched): 412 seconds
>> Patched Audacity 2.1.3 alpha: 6 seconds
>>
>> Question for James (RM), what do you want to do with this? I can send
>> you a patch for review if that will help.
>>
>> Steve
>>
>>
>> On 15 January 2017 at 15:02, Peter Sampson
>> <[hidden email]> wrote:
>>> Tested this on 07Jan17 Windows nightly and Mac debug nightly
>>> of 15Jan17.
>>>
>>> Testing by generating a 30 minute mono tone and then adding
>>> a track with 100 labels - using Niquist effect High Pass Filter
>>>
>>> 1)  On W10 there was no differebce between the two runs at c.15 seconds.
>>>
>>> 2) on Mac with debug build the no label track took 53 seconds
>>> wit the label track this extended to 64 seconds i.e. a 20% increase
>>>
>>> Peter.
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

James Crook
Steve,

I'm rejecting the pull request.  Thanks for making it.

The problem is that the short circuit evaluation of flags is creating
flags with value 0.
You can see this by putting a wxLogDebug at line 1978 of menus.cpp
(a breakpoint there instead will cause endless confusion in debugging
since every focus to/from track panel causes a change)

The zero appears to happen only during effects processing - and to be
restored after effects processing completes.  And as you can't see the
toolbar menus in that time it is 'safe'.  I expected the SyncLock icon
to pop-up during effect processing as a result, but it seems only menus
get refreshed, and those aren't seen.

However the correct behaviour is to maintain existing flags except for
the ones we are interested in updating.  flags is badly incorrect during
effect processing, and mCommandManager is being updated based on these
incorrect flags - so I can't accept the patch.  It's too fragile, and
isn't doing what one would expect/want.

I think a correct patch would recognise when short-circuit evaluation of
flags was being done, and ONLY update the relevant bits.

if( was a short circuit evaluation )
     flags = (mLastFlags & ~SpecialFlags) | flags

where SpecialFlags are the flags we update during short circuit evaluation.

--James.



On 1/16/2017 1:42 PM, Steve the Fiddle wrote:

> On 16 January 2017 at 11:56, James Crook <[hidden email]> wrote:
>>> Question for James (RM), what do you want to do with this? I can send
>>> you a patch for review if that will help.
>> It seems safe from my perspective, even with my hat on.
>>     18 seconds to 412 is a highly embarrassing regressions.
>>     18 seconds to 6 seconds is a very worthwhile improvement.
>>
>> So there is both carrot and stick to get these changes in.  And we're
>> not 'moments away' from having an RC.
>>
>> I don't want to commit them from a patch, but if there is a branch ready
>> to review/merge then I am ready to do so, and it is very likely to go in.
> I've made a pull request:
> https://github.com/audacity/audacity/pull/178
>
> Steve
>
>
>> --James (as RM)
>>
>>
>>
>>
>> On 1/16/2017 11:31 AM, Steve the Fiddle wrote:
>>> Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
>>> presume that you have?)
>>>
>>> There are now three parts to a full fix for this problem:
>>>
>>> 1) Reduce the calls to YieldFor to a reasonable rate.
>>> 2) Paul's fix for the label track issue.
>>> 3) Remove (comment out) the unused updating of TextClipFlag.
>>>
>>> Testing on my old dual core Pentium laptop with Debian stable with
>>> these three fixes:
>>> * There is no slowdown of Nyquist (or other) effects when there is a label track
>>> * There is "significant" improvement in the speed of Nyquist effects
>>> whenever the effect takes long enough to show a progress bar.
>>>
>>> Performance test:
>>> 30 minutes of audio, Silence Finder.
>>>
>>> No label track:
>>> Audacity 2.1.2, release build: 18 seconds
>>> Audacity 2.1.3 alpha (not patched): 18 seconds
>>> Patched Audacity 2.1.3 alpha: 6 seconds
>>>
>>> With label track:
>>> Audacity 2.1.2 release build: 18 seconds
>>> Audacity 2.1.3 alpha (not patched): 412 seconds
>>> Patched Audacity 2.1.3 alpha: 6 seconds
>>>
>>> Question for James (RM), what do you want to do with this? I can send
>>> you a patch for review if that will help.
>>>
>>> Steve
>>>
>>>
>>> On 15 January 2017 at 15:02, Peter Sampson
>>> <[hidden email]> wrote:
>>>> Tested this on 07Jan17 Windows nightly and Mac debug nightly
>>>> of 15Jan17.
>>>>
>>>> Testing by generating a 30 minute mono tone and then adding
>>>> a track with 100 labels - using Niquist effect High Pass Filter
>>>>
>>>> 1)  On W10 there was no differebce between the two runs at c.15 seconds.
>>>>
>>>> 2) on Mac with debug build the no label track took 53 seconds
>>>> wit the label track this extended to 64 seconds i.e. a 20% increase
>>>>
>>>> Peter.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Massive slow down of Nyquist effects when label track present

James Crook
I looked at it a bit more - and decided to preserve the bits that were
not being recalculated and so were 0.
So in the end I did pull this change in, and added that correction.

https://github.com/audacity/audacity/commit/0bc20269a771e643642ccdc53bd7f333d432f899

Will need retest on Linux and Mac.

--James.


On 1/16/2017 3:50 PM, James Crook wrote:

> Steve,
>
> I'm rejecting the pull request.  Thanks for making it.
>
> The problem is that the short circuit evaluation of flags is creating
> flags with value 0.
> You can see this by putting a wxLogDebug at line 1978 of menus.cpp
> (a breakpoint there instead will cause endless confusion in debugging
> since every focus to/from track panel causes a change)
>
> The zero appears to happen only during effects processing - and to be
> restored after effects processing completes.  And as you can't see the
> toolbar menus in that time it is 'safe'.  I expected the SyncLock icon
> to pop-up during effect processing as a result, but it seems only menus
> get refreshed, and those aren't seen.
>
> However the correct behaviour is to maintain existing flags except for
> the ones we are interested in updating.  flags is badly incorrect during
> effect processing, and mCommandManager is being updated based on these
> incorrect flags - so I can't accept the patch.  It's too fragile, and
> isn't doing what one would expect/want.
>
> I think a correct patch would recognise when short-circuit evaluation of
> flags was being done, and ONLY update the relevant bits.
>
> if( was a short circuit evaluation )
>       flags = (mLastFlags & ~SpecialFlags) | flags
>
> where SpecialFlags are the flags we update during short circuit evaluation.
>
> --James.
>
>
>
> On 1/16/2017 1:42 PM, Steve the Fiddle wrote:
>> On 16 January 2017 at 11:56, James Crook <[hidden email]> wrote:
>>>> Question for James (RM), what do you want to do with this? I can send
>>>> you a patch for review if that will help.
>>> It seems safe from my perspective, even with my hat on.
>>>      18 seconds to 412 is a highly embarrassing regressions.
>>>      18 seconds to 6 seconds is a very worthwhile improvement.
>>>
>>> So there is both carrot and stick to get these changes in.  And we're
>>> not 'moments away' from having an RC.
>>>
>>> I don't want to commit them from a patch, but if there is a branch ready
>>> to review/merge then I am ready to do so, and it is very likely to go in.
>> I've made a pull request:
>> https://github.com/audacity/audacity/pull/178
>>
>> Steve
>>
>>
>>> --James (as RM)
>>>
>>>
>>>
>>>
>>> On 1/16/2017 11:31 AM, Steve the Fiddle wrote:
>>>> Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
>>>> presume that you have?)
>>>>
>>>> There are now three parts to a full fix for this problem:
>>>>
>>>> 1) Reduce the calls to YieldFor to a reasonable rate.
>>>> 2) Paul's fix for the label track issue.
>>>> 3) Remove (comment out) the unused updating of TextClipFlag.
>>>>
>>>> Testing on my old dual core Pentium laptop with Debian stable with
>>>> these three fixes:
>>>> * There is no slowdown of Nyquist (or other) effects when there is a label track
>>>> * There is "significant" improvement in the speed of Nyquist effects
>>>> whenever the effect takes long enough to show a progress bar.
>>>>
>>>> Performance test:
>>>> 30 minutes of audio, Silence Finder.
>>>>
>>>> No label track:
>>>> Audacity 2.1.2, release build: 18 seconds
>>>> Audacity 2.1.3 alpha (not patched): 18 seconds
>>>> Patched Audacity 2.1.3 alpha: 6 seconds
>>>>
>>>> With label track:
>>>> Audacity 2.1.2 release build: 18 seconds
>>>> Audacity 2.1.3 alpha (not patched): 412 seconds
>>>> Patched Audacity 2.1.3 alpha: 6 seconds
>>>>
>>>> Question for James (RM), what do you want to do with this? I can send
>>>> you a patch for review if that will help.
>>>>
>>>> Steve
>>>>
>>>>
>>>> On 15 January 2017 at 15:02, Peter Sampson
>>>> <[hidden email]> wrote:
>>>>> Tested this on 07Jan17 Windows nightly and Mac debug nightly
>>>>> of 15Jan17.
>>>>>
>>>>> Testing by generating a 30 minute mono tone and then adding
>>>>> a track with 100 labels - using Niquist effect High Pass Filter
>>>>>
>>>>> 1)  On W10 there was no differebce between the two runs at c.15 seconds.
>>>>>
>>>>> 2) on Mac with debug build the no label track took 53 seconds
>>>>> wit the label track this extended to 64 seconds i.e. a 20% increase
>>>>>
>>>>> Peter.
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
12
Loading...