[Audacity-devel] Massive slow down of Nyquist effects when label track present

[Steve the Fiddle]

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

[Roger Dannenberg]

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

Post by Steve the Fiddle
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Steve the Fiddle]

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

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

[Roger Dannenberg]

More below...

Post by Steve the Fiddle
Thanks for the response Roger. Comments in-line below.

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.

Post by Steve the Fiddle
YiedFor is called on every loop through ProgressDialog::Update
Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
Time taken = 22 seconds
Number of call to YieldFor = 70381
Time taken = 555 seconds
Number of calls to YieldFor = 72670
Time taken = 8 seconds
Count through Update = about 76000
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.

Post by Steve the Fiddle
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 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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Steve the Fiddle]

Post by Roger Dannenberg
More below...
Thanks for the response Roger. Comments in-line below.
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.

Post by Roger Dannenberg
YiedFor is called on every loop through ProgressDialog::Update
Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
Time taken = 22 seconds
Number of call to YieldFor = 70381
Time taken = 555 seconds
Number of calls to YieldFor = 72670
Time taken = 8 seconds
Count through Update = about 76000
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

Post by Roger Dannenberg
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 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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Roger Dannenberg]

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

Post by Steve the Fiddle

Post by Roger Dannenberg
More below...
Thanks for the response Roger. Comments in-line below.
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.

Post by Roger Dannenberg
YiedFor is called on every loop through ProgressDialog::Update
Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
Time taken = 22 seconds
Number of call to YieldFor = 70381
Time taken = 555 seconds
Number of calls to YieldFor = 72670
Time taken = 8 seconds
Count through Update = about 76000
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

Post by Roger Dannenberg
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 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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale]

On 11 January 2017 at 22:13, Roger Dannenberg <

Post by Roger Dannenberg
More below...
Thanks for the response Roger. Comments in-line below.
On 11 January 2017 at 17:27, Roger Dannenberg <
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

Post by Roger Dannenberg
YiedFor is called on every loop through ProgressDialog::Update
Applying High Pass filter on a mono track, 17 mins duration, 44100 Hz.
Time taken = 22 seconds
Number of call to YieldFor = 70381
Time taken = 555 seconds
Number of calls to YieldFor = 72670
Time taken = 8 seconds
Count through Update = about 76000
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

Post by Roger Dannenberg
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 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

--
View this message in context: http://audacity.238276.n2.nabble.com/Massive-slow-down-of-Nyquist-effects-when-label-track-present-tp7577753p7577766.html
Sent from the audacity-devel mailing list archive at Nabble.com.

[James Crook]

Post by Gale
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.

[Steve the Fiddle]

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.

Post by James Crook

Post by Gale
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

Post by James Crook
--James.

[Steve the Fiddle]

The big slowdown in Nyquist when a label track is present seems to be
a recent problem. I'll continue investigating.

Steve

Post by Steve the Fiddle
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.

Post by James Crook

Post by Gale
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

Post by James Crook
--James.

[Steve the Fiddle]

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

Post by Steve the Fiddle
The big slowdown in Nyquist when a label track is present seems to be
a recent problem. I'll continue investigating.
Steve

Post by Steve the Fiddle
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.

Post by James Crook

Post by Gale
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

Post by James Crook
--James.

[Paul Licameli]

Post by Steve the Fiddle
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
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).
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

Post by Steve the Fiddle

Post by Steve the Fiddle
The big slowdown in Nyquist when a label track is present seems to be
a recent problem. I'll continue investigating.
Steve

Post by Steve the Fiddle
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.

Post by James Crook

Post by Gale
Is this a safe and simple fix? I might call the bug P1 unless James

strongly

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook

Post by Gale
opposes it, given it's a bad regression on 2.1.2 and we have two

outstanding

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook

Post by Gale
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

Post by James Crook
--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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Paul Licameli]

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

Post by Steve the Fiddle
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
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).
if (checkActive && !IsActive())
Steve

Post by Steve the Fiddle
The big slowdown in Nyquist when a label track is present seems to be
a recent problem. I'll continue investigating.
Steve

Post by Steve the Fiddle
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.

Post by James Crook

Post by Gale
Is this a safe and simple fix? I might call the bug P1 unless James

strongly

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook

Post by Gale
opposes it, given it's a bad regression on 2.1.2 and we have two

outstanding

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook

Post by Gale
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

Post by James Crook
--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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[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

Post by Paul Licameli
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 <

Post by Steve the Fiddle
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
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).
if (checkActive && !IsActive())
Steve

Post by Steve the Fiddle
The big slowdown in Nyquist when a label track is present seems to be
a recent problem. I'll continue investigating.
Steve

Post by Steve the Fiddle
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.

Post by James Crook

Post by Gale
Is this a safe and simple fix? I might call the bug P1 unless James

strongly

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook

Post by Gale
opposes it, given it's a bad regression on 2.1.2 and we have two

outstanding

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook

Post by Gale
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

Post by Steve the Fiddle

Post by Steve the Fiddle

Post by James Crook
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

Post by James Crook
--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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Peter Sampson]

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.

[Steve the Fiddle]

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

Post by Peter Sampson
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by Steve the Fiddle
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)

Post by Steve the Fiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)
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
* 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.
30 minutes of audio, Silence Finder.
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
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

Post by Peter Sampson
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Steve the Fiddle]

Post by James Crook

Post by Steve the Fiddle
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

Post by James Crook
--James (as RM)

Post by Steve the Fiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)
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
* 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.
30 minutes of audio, Silence Finder.
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
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

Post by Peter Sampson
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[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.

Post by Steve the Fiddle

Post by James Crook

Post by Steve the Fiddle
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.

https://github.com/audacity/audacity/pull/178
Steve

Post by James Crook
--James (as RM)

Post by Steve the Fiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)
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
* 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.
30 minutes of audio, Silence Finder.
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
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

Post by Peter Sampson
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[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.

Post by 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.

Post by Steve the Fiddle

Post by James Crook

Post by Steve the Fiddle
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.

https://github.com/audacity/audacity/pull/178
Steve

Post by James Crook
--James (as RM)

Post by Steve the Fiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)
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
* 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.
30 minutes of audio, Silence Finder.
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
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

Post by Peter Sampson
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Steve the Fiddle]

Thanks James, and thanks for the explanation. Still looks good on
Linux, and I'm now seeing sensible flags in debug.

Steve

Post by 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.

Post by 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.

Post by Steve the Fiddle

Post by James Crook

Post by Steve the Fiddle
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.

https://github.com/audacity/audacity/pull/178
Steve

Post by James Crook
--James (as RM)

Post by Steve the Fiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)
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
* 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.
30 minutes of audio, Silence Finder.
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
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

Post by Peter Sampson
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
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Cliff Scott]

Tested on Sierra 10.12.2 and it is a massive improvement in speed. Verified the label track issue with a Dec. 30 build and compared with the build today. Even Normalize is at least twice as fast now and other effects even a bigger change. No problems noted. Interesting that all the nyquist plugins I tried were significantly improved except Paul's DeClicker. No difference when run on the same file in the new and old builds. Something must be special in how it was written.

Great job Steve!

Cliff

Post by 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.

Post by 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.

Post by Steve the Fiddle

Post by James Crook

Post by Steve the Fiddle
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.

https://github.com/audacity/audacity/pull/178
Steve

Post by James Crook
--James (as RM)

Post by Steve the Fiddle
Thanks Paul, that works fine on Linux (I've not tested on Mac, but I
presume that you have?)
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
* 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.
30 minutes of audio, Silence Finder.
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
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

Post by Peter Sampson
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
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Peter Sampson]

Tested on latest alpha 17Jan17 292a74f and on 2.1.2 on Mac Sierra 10.12.2

Works fine on latest alpha - a big 5x improvement on 2.1.2 and no increase
in time if a label track is present.

20 Seconds mono noise, with and without 100 labels label track, High Pass
Filter

On 2.1.3 alpha => 3 seconds

On 2.1.2 => 14 seconds

Great job Steve.

Peter.

[Peter Sampson]

Post by Peter Sampson
20 Seconds mono noise, with and without 100 labels label track, High Pass

Filter

Oops should say: "30 minutes mono noise ... "

Peter.