Raised to a P2.

Audacity does a MakeParentPushState with every label character, which in turn does an AutoSave, which saves the entire project, not just changes.  No wonder things are slow with audio of around an hour.  Autosaving the entire project on every keypress is madness.  


If we disable AutoSave like so:

void AudacityProject::AutoSave()
{
   return;

we are back to acceptable speeds.  There is still a small delay in reflecting characters entered in labels, because Audacity is redrawing the entire screen.


r10509 on 1st July made AutoSave non-optional:
"Get rid of AutoSaveEnabled pref altogether. AutoSave doesn't copy any audio
data, so there's no reason to turn it off."

A possible solution is where we currently autosave to instead set a flag, 'autosave needed' which we periodically check.

(In reply to comment #1)
> Audacity does a MakeParentPushState with every label character, which in turn
> does an AutoSave, which saves the entire project, not just changes.  No wonder
> things are slow with audio of around an hour.  Autosaving the entire project on
> every keypress is madness.  
>
>
> If we disable AutoSave like so:
> 
> void AudacityProject::AutoSave()
> {
>  return;
>
> 
> we are back to acceptable speeds.  There is still a small delay in reflecting
> characters entered in labels, because Audacity is redrawing the entire screen.
>
>
> r10509 on 1st July made AutoSave non-optional:
> "Get rid of AutoSaveEnabled pref altogether. AutoSave doesn't copy any audio
> data, so there's no reason to turn it off."
> 
> A possible solution is where we currently autosave to instead set a flag,
> 'autosave needed' which we periodically check.
Thanks for your investigations. 

Won't periodically autosaving lead us back into broken crash recoveries? We cannot go back to that. Autosaving on every change of state was IMO the right decision. 

But is this also the explanation of expanding selections with the keyboard (for example, SHIFT + right arrow) - it's saving every arrow push? I don't understand that, because drawing selections isn't a change of state. 

For the typing of characters, can we not group characters for saving purposes  e.g. as we do for undo where we undo every group of three characters?  How expensive would it be to run a timer and save only when no characters have been input for x ms?  

As for the rating, as with other borderline P2/P3s, someone needs to assign themselves, otherwise I will demote it back to P3. We have to stop adding P2 if we want to get 2.0 out. I *really* wanted to make this P2, but we just can't afford the luxury any more to do this.

(In reply to comment #2)
> is this also the explanation of expanding selections with the keyboard (for
> example, SHIFT + right arrow) - it's saving every arrow push? I don't
> understand that, because drawing selections isn't a change of state. 
Answering my own question, although drawing a selection is not a change on the undo stack, yes every single arrow push is saved in the autosave file.

I disabled autosave as James suggested. On my Win 7 x64 machine with an hour long mono track, at best it's a 50% improvement. If I type the previous sentence all at once in a label with autosave disabled, I wait about 2 - 3 seconds for the text. With current HEAD I wait about 4 - 5 seconds. So I guess 10903 adds to the autosave problem? 

With 1.3.12 the characters type at once. As for number of complainants, it's five people that I know about (including Peter and the Forum) for 1.3.13 Beta, and seven including the old 1.3.13 alpha.

OK.  I am on a fast machine, but I still see this when I have a 10hr recording.

I've added some code that for changes which are 'consolidated' on the undo stack take two shortcuts - avoiding autosaving and avoiding calculating the true size.  Both are expensive operations since both involve iterating through all the audio files.  Consolidated changes are the ones we expect to happen in quick succession.  In the history the sizes will be zero for these changes.

It is NOT a fix, but it ameliorates the problem somewhat.  The undo mechanism is still 'duplicating' all audio (by reference) even though the audio is unchanged.  The fact that PushState takes significant time on long recordings is the root of the problem.  Saving just changes for these kind of edits rather than entire snapshots would solve this, but would be more complex.  If I hack Audacity to do no pushstate for label track characters I get responsive labels even with a 10hr recording.

Change is in SVN 11173

(In reply to comment #4)
Thanks, James.

Aside from getting 2.0 out, my reasoning for the initial rating of P3 is that on slower machines the Audacity experience already deteriorates considerably once you have an hour of audio. Look at the hangs fitting to the window and waiting after effects complete to see the results.  

I understand the irritation if you are labelling long projects, but (even in 1.3.13 Beta as released) I think all you need to do is slow down to about 3 key presses per minute. If that is too slow for the speed of playback, zoom out a notch. I find the experience responsive then (on two hours of audio) - I see each character as I type it.    

I'll test out your changes soon. If results are reasonable can we agree to demote this to P3?  


> If I hack Audacity to do no pushstate for label track characters I get 
> responsive labels even with a 10hr recording.
We'll see, but on slower machines I wonder if speed-typers in long projects are ever going to be 100% happy even with your amelioration, unless we find an alternative solution to bug 255 and bug 148? You will still get faster response in 1.3.12.

(In reply to comment #5)
James I updated to HEAD Unicode Release on Win 7, but it doesn't seem to autosave at all. Generate a tone and force quit, no recovery. Generate a tone and add labels, force quit, no recovery. Record for 2 minutes and force quit, no recovery. Yes I deleted build folder and cleaned solution. Do you see this? If not, yet another fresh checkout I suppose...

Oops.  I'd inadvertently left the hack in described in comment#2.

I've fixed that in SVN now.  Thanks.

(In reply to comment #7)
James, OK I've tested with your comment 2 hack removed on Win 7 x64. I imported two hour long files and played the tracks and recorded overdub.  

Summary: Not sure if more can be done to recover label text. Dragging selections with keyboard has not been improved.   

* Label creation (CTRL + B or CTRL + M ) - on direct comparison with 1.3.12, this is slower and still stops progress of the playback or recording cursor in HEAD but doesn't seem to in 1.3.12.

* Label typing - seems as responsive as 1.3.12, not just "50% faster" as when  only your comment 2 hack was in place (also tested typing names in tracks). However it appears no autosaving is done while the label is being typed in, irrespective of number of characters. Also ENTER to hit the label does not cause autosave, although OK when naming a track does an autosave. So AFAICT if you crash while typing a label (and didn't click in the label), you lose the entire label text on recovery, even if you did ENTER and crashed after that.  

* Dragging selection with keyboard (i.e. SHIFT + left or right arrow when track is static). No improvement, every key press is autosaved. Holding SHIFT + left or right is too slow drawing compared to 1.3.12. If you have enough audio, it does not draw at all until you release the keys.  

* Dragging selections with the mouse (whether track active or not) - it seems to be improved - at least as responsive as 1.3.12.

* Dragging tracks vertically - OK but I could never reproduce an issue. We'll see what complainant on Vista says.      

* Gain sliders weren't reported as a problem before, so don't know if anyone cares the slider setting won't be recovered if there is a crash after a slider change.

Gale,

The results you see are much as I would expect.  If you go into history window you'll also see the size after label edits as 0.0 bytes rather than e.g. 6.6 Gb.  As I said it is only an amelioration, not a true fix.

Label creation and dragging selection, and indeed almost any other edit can be made faster by skipping the sizing calculation and autosave - if we want.  My own view of autosave is that it is crucial for recording (where it is actually done efficiently) and of lower importance for labels.  We could perhaps do an autosave and correct sizing on a label completion.  Or rely on a periodic autosave to rescue us.

History really needs a lot more work.  It's sufficiently clunky in its current implementation that an option to switch it off would be an enhancement, in spite of option-creep.

Will I do the change for dragging selections by keyboard?  Label creation?

James,

My view is that we should at a minimum do autosave on label completion. If it was possible I would even try it (say) it every six label characters. People who care about labels for annotation do care about the label text in my experience. 

I'm not following about the History window. In 1.3.13 Beta as released, typing a character in a label or editing a label also shows as 0.0 bytes even in large projects. What History clunkiness do you have in mind? I think "Undo Levels available" and "Levels to discard" is relatively unintuitive. There are some votes on Feature Requests for a Preference to turn History off, but the rationale is disk space saving. 

Periodic autosave as implemented clearly did not work well - it could fail to recover the most important changes (audio - and even recordings). I think we are better to start from autosaving all changes and take some incremental saves out. 


> Will I do the change for dragging selections by keyboard?  Label creation? 
Clearly both those things are irritating some users so I'm glad you are working on this, though neither those or the unresponsive labels are P2 IMO given the need to release 2.0. There are stronger P2 candidates e.g.
bug 15 and bug 32 which unlike this bug don't even have workarounds. 

Keyboard selection dragging could be autosaved every n key presses if it's possible. To me that would be the best solution because there is no "expected" action after dragging a selection that "confirms" the selection. The label creation point or region is obviously important so I think it should be autosaved. I'm not following why it's so slow - in 1.3.13 Beta as released, up to three key presses per minute can be autosaved without a holdup (with an hour or two of audio). Is it because we are refreshing the screen? 
 
An enhancement issue to to only save changes when audio hasn't changed should  rate as P4, would you say?

(In reply to comment #1)

> Audacity does a MakeParentPushState with every label character, which in turn
> does an AutoSave, which saves the entire project, not just changes.  No wonder
> things are slow with audio of around an hour.  Autosaving the entire project on
> every keypress is madness.  

When I made Autosave work correctly (as the timer stuff was never implemented), I did not go through *every* PushState call to see whether it was reasonable.

I say that PushState on every keypress is the madness part, that the PushState should be when the user completes the label.


> 
> 
> If we disable AutoSave like so:
> 
> void AudacityProject::AutoSave()
> {
>    return;
> 
> we are back to acceptable speeds.  There is still a small delay in reflecting
> characters entered in labels, because Audacity is redrawing the entire screen.
> 
> 
> r10509 on 1st July made AutoSave non-optional:
> "Get rid of AutoSaveEnabled pref altogether. AutoSave doesn't copy any audio
> data, so there's no reason to turn it off."
> 
> A possible solution is where we currently autosave to instead set a flag,
> 'autosave needed' which we periodically check.
> 

Disagree. If we do PushStates when state actually changes, there's no need to periodically check anything. 

There are lots of changes the user can make that do not do a PushState. For instance, changing selection. That originally did cause a PushState, but a decision to not do so was made several years ago (and I argued against it at the time, because you have to Region Save/Restore now). Anyway, point is that there are other user changes that do not PushState.

(In reply to comment #2)

> [...]
>> A possible solution is where we currently autosave to instead set a flag,
>> 'autosave needed' which we periodically check.
> Thanks for your investigations. 
> 
> Won't periodically autosaving lead us back into broken crash recoveries? We
> cannot go back to that. Autosaving on every change of state was IMO the right
> decision. 

Right. We had a lot of discussion back then about how checking a timer is pointless if the user's not doing anything, and then necessarily causes project problems if the user crashes somewhere in the timer interval.

> 
> But is this also the explanation of expanding selections with the keyboard (for
> example, SHIFT + right arrow) - it's saving every arrow push? I don't
> understand that, because drawing selections isn't a change of state. 

Yeah, I don't think that's related. 


> [...]
> 
> As for the rating, as with other borderline P2/P3s, someone needs to assign
> themselves, otherwise I will demote it back to P3. We have to stop adding P2 if
> we want to get 2.0 out. I *really* wanted to make this P2, but we just can't
> afford the luxury any more to do this.
> 

Bravo!

Consolidating my responses. And sorry I couldn't participate 
in this discussion when it was most active. 


> (In reply to comment #2)
>> is this also the explanation of expanding selections with the keyboard (for
>> example, SHIFT + right arrow) - it's saving every arrow push? I don't
>> understand that, because drawing selections isn't a change of state. 
> Answering my own question, although drawing a selection is not a change on the
> undo stack, yes every single arrow push is saved in the autosave file.

Thanks for checking. I think that's another case where it makes no sense to PushState. 

> 
> [...]
> 
> With 1.3.12 the characters type at once. As for number of complainants, it's
> five people that I know about (including Peter and the Forum) for 1.3.13 Beta,
> and seven including the old 1.3.13 alpha.
> 

So rather than James' changes for this, I think we should have figured out what changed. This is a recent bug report, but I fixed AutoSave last summer.



> --- Comment #4 from James Crook <james.k.crook@gmail.com> 2011-05-22 10:10:48 EDT ---
> OK.  I am on a fast machine, but I still see this when I have a 10hr recording.
> 
> I've added some code that for changes which are 'consolidated' on the undo
> stack take two shortcuts - avoiding autosaving and avoiding calculating the
> true size.  Both are expensive operations since both involve iterating through
> all the audio files.  

I don't think that's true of AutoSave. AutoSave just writes a spare of the .aup. I haven't checked every WriteXML and SaveXML, but I did check them for WaveTracks/Clips/Sequences, and it doesn't look at the audio files, just values of member vars on class instantiations. 



>Consolidated changes are the ones we expect to happen in
> quick succession.  In the history the sizes will be zero for these changes.

Not sure, but I think this is an unnecessary complication. 


> 
> It is NOT a fix, but it ameliorates the problem somewhat.  The undo mechanism
> is still 'duplicating' all audio (by reference) even though the audio is
> unchanged.  

So we should make decisions to not PushState on those, either. Is that a reasonable rule of thumb, that if audio doesn't change, do not PushState?

(In reply to comment #0)

> Regression on 1.3.12. Suspected
> http://code.google.com/p/audacity/source/detail?r=10903 as the cause but have
> built from SVN at 24 hours before 10903 and it has the same issue.  

Right, so I think this is more likely related to Roger's full-redraws for the WaveTrack vertical lines problems, rather than anything with AutoSave... We really need to draw only a few pixels wide for each of those, rather than the full visible TrackPanel.

(In reply to comment #13)
>> With 1.3.12 the characters type at once. As for number of complainants, it's
>> five people that I know about (including Peter and the Forum) for 1.3.13 Beta,
>> and seven including the old 1.3.13 alpha.
> So rather than James' changes for this, I think we should have figured out what
> changed. This is a recent bug report, but I fixed AutoSave last summer.
One more report since comment 13. I guess the above reflects the small number of users of alpha builds. 


> if audio doesn't change, do not PushState?
I don't think we need to go that far? PushStates only seem to be a practical problem if doing it multiple times per second.  

Also see http://bugzilla.audacityteam.org/show_bug.cgi?id=40#c3 - rapid typing in a label or label track can cause a screen jump (though James's current fix makes this harder to reproduce outside the steps in 40#c3). Confusingly, in 1.3.12 the jump would only occur if an autosave resulted. In 1.3.14 the jump occurs even if autosave is disabled.

>> --- Comment #4 from James Crook <james.k.crook@gmail.com> 2011-05-22 10:10:48 EDT ---
>> OK.  I am on a fast machine, but I still see this when I have a 10hr recording.
>> 
>> I've added some code that for changes which are 'consolidated' on the undo
>> stack take two shortcuts - avoiding autosaving and avoiding calculating the
>> true size.  Both are expensive operations since both involve iterating through
>> all the audio files.  
> 
> I don't think that's true of AutoSave. AutoSave just writes a spare of the
> .aup. I haven't checked every WriteXML and SaveXML, but I did check them for
> WaveTracks/Clips/Sequences, and it doesn't look at the audio files, just values
> of member vars on class instantiations. 

I profiled this several times with 10 second durations at 1ms samples.  It appears AutoSave does force the SaveXML for every wavetrack and blockfile, but that this is a major but *not* the main CPU suck.  Autosave/UndoManager took around 15-25% of the non-sleep samples in the main thread and TrackPanel::OnPaint take a little more than half.
These are probably both worth looking into.

I was typing about 3-4 characters a second with occassional pauses.  There was notable but tolerable lag in typing.

However, I did notice moments of severe lag when I couldn't type for a few seconds.  I caught these on the profiler as well and these cases had 90% of the samples in the below TrackPanel::OnChar()'s MakeParentPushState's UndoManager::CalculateSpaceUsage().  So for the jerkiness this is where I would look.


AutoSave is called from a bunch of different places so it is not so easy to profile, but I also noted that we are probably doing too many PushStates anyway.

Also the undo manager may be worth looking at - here is one snippet:

TrackPanel::OnChar
  TrackPanel::MakeParentPushState
    AudacityProject::TP_PushState
      AudacityProject::PushState (this branch does not AutoSave)
        UndoManager::PushState
LabelTrack::OnChar (this is not from within TrackPanel::OnChar and so is a seperate stack)
  AudacityProject::PushState
    UndoManager::PushState 
      AudacityProject::PushState

I will try to see if I can think of a cleverer way of calling or avoiding UndoManager's CalculateSpaceUsage in these cases.

If that doens't help much the next candidate is TrackPanel/Roger's changes to see if I can find the root of the cause of the drawing issue as this seems to be the bigger problem.

After that it might be worth modifying the use *PushState to be less continuous and more based on boundaries of dragging and label entry events

Also I profiled for simple track selection by dragging and you get fairly similar sources for continuous lag, but I didn't see the sudden decrease in responsiveness with CalculateSpaceUsage.  Not sure why.

(In reply to comment #16)
Thanks, Michael for your investigations.  

I see three issues at the moment (all P2/P3 borderline, needs someone to assign themselves if it is to remain as P2):     

* Label creation (CTRL + B or CTRL + M ) - still slow enough to stop progress of the playback or recording cursor in HEAD, but doesn't do so in 1.3.12.

* Dragging selections with the keyboard (e.g. hold SHIFT and left or right arrow) - selection may not get drawn until after release if you have sufficient hours of audio AND key press more than 3 or 4 times per second). Dragging with the mouse seems much less of an issue. 

* Potential loss of label text if you crash (regression introduced by current fix) - even if you have closed a label, its text will not be recovered unless you did something else to do a PushState afterwards.   


> it might be worth modifying the use *PushState to be less continuous
> and more based on boundaries of dragging and label entry events
Yes that was my initial feeling too. 

Having compared HEAD with autosave disabled with a build made just before Roger's changes also with autosave disabled, I do think Roger's changes are causing some extra delay, especially with label creation and dragging selections with the keyboard. This is only apparent on my Win 7 system with more than 1.5 hours of audio, but the difference seems to be consistently there.

fix committed in r11192.  Please test and check to see if  it is enough to close the bug.

Commmit notes:
Undoes Roger's fixes for bug 255/148, as this was one component of the bug.
This fix restores TrackPanel::RefreshTrack to using a cliprect instead of doing	an entire refresh.
It does	it by using a repair flag in TrackPanel::DoDrawIndicator that does not advance the indicator time (so the only place the time can advance is in	OnTimer)

I tested to make sure both bugs were okay after my fix.

This fix may restore usability enough to resolve the bug, but I note that there are other potential optimizations we can make, discussed on the bug 406 bugzilla comments.

I still want to look at some remaining issues with CPU usage brought up in the comments, which incidentally affects this bug, but that doesn't require this bug left open if performance is deemed satisfactory.

(In reply to comment #18)
Tested with 1.3.14-alpha June 5, Mac PPC 10.5.8.

* Label typing now has no noticeable lag using a project with one 2 hr 45 min stereo track. This same project exhibits the lag in 1.3.13-beta.
* "Dragging" a selection with the keyboard (shift+arrow) still has a lag using the long project.
* Dragging a selection with the keyboard has no lag using a project with a 30-second generated mono tone but displayed to the same size as the long project.
* The spurious cursor lines do not appear when manipulating the gain or pan sliders in the track control panel, nor when manipulating the gain slider in the mixer board.

Summary. Demoted to P3 (not closed because keyboard selection dragging and label creation still lagged). New issue identified with hangs when cutting, silencing etc. which have been improved but not fixed by latest commit. To be decided if this needs a new bug. A Wiki page for this bug or a related new bug might be needed.   

----     

Thanks for testing, Bill. I've done tests in 1.3.14 alpha (comparing with 1.2.6 and 1.3.12) using mainly 90 minute copied in WAVs and 90 minute saved projects. OS'es:  Win XP, Win 7 x64, Win 7 32-bit and Ubuntu 10.10 (both the latter on a 1.6 GHz, 1 MB RAM netbook). 

* Label creation (CTRL + B or CTRL + M ) - only a little improvement. The label can still take one or two seconds to appear and can still stop progress of the playback or recording cursor. Doesn't do so in 1.3.12. With autosave disabled in addition to Michael's latest fixes, it seems to be almost as quick as 1.3.12 - but not quite.   

* Dragging selections with the keyboard (faster than 3 or 4 keypresses a second) - almost no improvement, deemed unacceptable. Problem disappears completely if autosave is disabled.    

* No unreasonable problems dragging selections with the mouse - it is not quite as responsive in 3 hours of audio as with 3 minutes, but I would not expect it to be.     

* The spurious cursor lines do not appear when manipulating the gain or pan
sliders in the track control panel, nor when manipulating the gain slider in
the mixer board. 

* Typing labels with the keyboard - I think a little more responsive again than before Michael's fix - I need three hours of imported audio before I see lag but only needed 1.5 hours before. But we have the introduced regression of possibly lost label text if there is a crash. 

---- 

Another issue is coming to light that was reported once or twice on Windows since 1.3.8 but has been reported several times in 1.3.13 - editing actions that don't have a progress dialogue are taking excessive amounts of time in longer projects. All these have been cited on Win XP or Win 7:

* Cut, Copy, Paste, Silence (Edit menu items or buttons)
* Draw Tool sample moving

Peter has commented the Edit menu items are 50% slower in 1.3.14 (pre-Michael's latest fix) than in earlier Betas or 1.2.6, but he is only reporting times of 3 or 4 seconds versus 2 seconds. I've seen reports of up to a minute to delete or silence a section of audio in an hour or longer project. 

On my tests on Win 7 x64 (repeated on three fresh boots), I see with 90 minutes of copied in audio the following time to delete (or undo delete of) 15 minutes of audio: 

* 1.2.6 - 2 seconds
* any 1.3.x alpha or Beta until Michael's fix - 30 seconds
* current HEAD - 5 seconds 

Another Win 7 user on Forum has an identical experience. On XP (same machine), I see 2 seconds for 1.2.6, 10 seconds for 1.3.x until latest fix and about 5 seconds for HEAD. 

I also note the really excessive times on Win 7 prior to the latest HEAD are much reduced when reopening *saved projects* with copied in audio. I'm quite surprised by these findings but as a note of caution, one other Win 7 x64 user I'm in touch with sees no consistent improvement in 1.3.14 e.g. sometimes he waits 20 seconds to move a sample with Draw Tool, but sometimes it's responsive, without any obvious explanation. On my netbook running HEAD (Ubuntu 
Win 7 32-bit) I still typically get about 30 seconds delay silencing or deleting (down from average 50 seconds pre-latest commit). Hangs are usually accompanied by "Not Responding" on Win or greyed out window on Ubuntu, but do not seem associated with excessive CPU or swapping. I guess we ought to watch Win Vista and 7 and slow machines generally here.    

> I still want to look at some remaining issues with CPU usage brought up in the
> comments, which incidentally affects this bug, but that doesn't require this
> bug left open if performance is deemed satisfactory.
I've demoted the bug to P3 but it can't be closed IMO because of the dragging with keyboard, label creation and label text regression issues.  

Michael, if you don't think the problems with slow Cut, Silence etc. are related to any issues you point to here, please say and we'll start a new P3, at least to keep an eye on it. Issue is noted in (and should remain in) the Release Notes in this bug, though.

I looked into speeding up selection.  The slowdown boils down to excessive redrawing of the entire track panel instead of just the essential parts.
I commented out some of these redraws so that it wouldn't happen when the mouse is down (so the display isn't correct until mouse-up), and things are much much snappier.
However, since it is a bunch of work and we are scheduled to redo trackpanel post 2.0, I am not touching this now.

The Win 7 x64 user I referred to in comment 20 now sees consistent improvement in times taken to cut or silence compared to 1.3.13, having removed "Vipre antivirus" http://www.vipreantivirus.com/. We are still taking about 5 - 10 seconds in HEAD compared to a couple of seconds in 1.2.6 for comparable length of project.      

I think we still need to investigate limiting autosaves on repetitive actions as part of the approach to this bug. It would undoubtedly help the problem when dragging selections with the keyboard. Mouse dragging a selection is nothing like as slow but this is not an option for some users.

Added note to Release Notes about slowness or hang dragging samples with Draw Tool - been mentioned several times recently on Mac and Windows.

Created attachment 409 [details]
Provides some relief to the selection "hang"

This patch adds the ability for the keyboard based commands (like cursor left, extend selection right, etc.) to know when the key has been released.

When the patch is applied the current state is saved only when the key is released and not every time it repeats.

Here's an example of the difference it makes.

This video show the selection "hang", but also watch the CPU usage.  All I'm doing is pressing SHIFT+RIGHT ARROW.

http://youtu.be/tdMntDwGSkM

This one is the same thing bug with the patch applied.  Notice that the selection "hang" no longer occurs and look at the CPU usage!

http://youtu.be/EpXNsQ4Cky0

Created attachment 410 [details]
Provides some relief to the selection "hang"

Original patch had a bit from another...removed.

Results are just as dramatic on OSX.

(In reply to comment #26)
WOW! It makes a HUGE difference on Linux too.

Testing on Debian Stable with a 1 hour recording - Pre-patch: selecting with shift + cursor key is painfully slow. After patching it is extremely responsive.

I assume too much code change for 2.0.5? Will probably be very beneficial for machines that can only just about run Audacity once there is more than an hour of audio. 

Tested with only essential programs and services running. 

With Mac Mini 2012 4 GB RAM on a 2 hour mono track I see no speed benefit but only about 20% CPU instead of 60%. 

On Win 7 x64 dual core 6 GB RAM 2.4 GHz on a 2 hour mono track I see a good speed benefit and CPU is about 50% instead of 100%. The improvement is occasionally much more dramatic than that. 

On my Linux netbook Audacity would usually hang and have to be force quit doing a keyboard selection on a 2 hour track in current HEAD. So I assume this would be an improvement but I did not test as Steve had done so.

(In reply to comment #25)
> Created an attachment (id=410) [details]
> Provides some relief to the selection "hang"
> 
> Original patch had a bit from another...removed.

tested on windows 7:
with patch:
- speed cursor moves when pressing left or right arrow now doesn't seem to depend on length of audio (up to 2 hrs, anyway)
- speed of selection change when presing shift + left/right or shift + crtl + left/rigth also don't seem to depend on length of audio.
Both are useful changes.

(if you do the same sort of things by incrementing/decrementing digits in the selection start and end/length controls in the selection bar, then their responsiveness still depends on the length of audio, though I don't think this is a big problem.)

David.

Created attachment 413 [details]
Improve performance of selection via Selection bar

This provides a similar type of speed up when selecting with the keyboard via the Selection toolbar.

(In reply to comment #29)
> (In reply to comment #25)
> > Created an attachment (id=410) [details] [details]
> > Provides some relief to the selection "hang"
> > 
> > Original patch had a bit from another...removed.
> 
> tested on windows 7:
> with patch:
> - speed cursor moves when pressing left or right arrow now doesn't seem to
> depend on length of audio (up to 2 hrs, anyway)
> - speed of selection change when presing shift + left/right or shift + crtl +
> left/rigth also don't seem to depend on length of audio.
> Both are useful changes.
> 
> (if you do the same sort of things by incrementing/decrementing digits in the
> selection start and end/length controls in the selection bar, then their
> responsiveness still depends on the length of audio, though I don't think this
> is a big problem.)

It's really sort of the same issue, so I've attached a separate patch.

(In reply to comment #31)
> (In reply to comment #29)
> > (In reply to comment #25)
> > > Created an attachment (id=410) [details] [details] [details]

> > (if you do the same sort of things by incrementing/decrementing digits in the
> > selection start and end/length controls in the selection bar, then their
> > responsiveness still depends on the length of audio, though I don't think this
> > is a big problem.)
> 
> It's really sort of the same issue, so I've attached a separate patch.

that fixes it - much more responsive when then length of audio is long.
thanks,
David.

(In reply to comment #28)

> I assume too much code change for 2.0.5? Will probably be very beneficial for
> machines that can only just about run Audacity once there is more than an hour
> of audio.

You mean only about the 2nd patch, right, which is actually "sort of the same issue"... so not actually, and adds to the testing. Neither of these appears to be a dangerous change (to me), or require string changes, but we have agreed to code freeze on Oct 15, so that would require a good bit more testing, I think, in only 5 days. 

Even if all our internal QA testing has actually already been done on this patch, that's only a few people (3?). 

This is a release to fix egg-on-our-face crashes and failures on standard file-open features. These changes might engender more, that our small team missed, and that hasn't been alpha-tested to any real degree. Let's not introduce any more impediments or complications to getting 2.0.5 out ASAP. 

I can be lobbied otherwise, but as posted, I would like us to release 2.0.6 in about 2 months, so it's not as if this will wait long. 

(And do we need to visit this issue of marking "patch_ready" if only one of two patches is considered so?)

(In reply to comment #33)
I've removed "patch_ready". If you want my opinion, leave these changes out of 2.0.5, which is why I questioned it. I don't have 100% confidence we could fully test around everything it may impact before the 15th. 
 
My "patch_ready" was explicitly for the first "Provides some relief to the selection "hang"". 

Then Leland added the second "Improve performance of selection via Selection bar", which was thus explicitly not "patch_ready", but he did not remove the "patch_ready".  

Then David reviewed the second patch, so I decided to leave "patch_ready" in there for you to decide.

I meant the "patch_ready" to apply to both patches, but I agree it can be confusing for Vaughan if there are multiple patches and "patch_ready".  I don't know myself if the second patch was supposed to replace the first or to be applied after the first.

Best to discuss how we can improve "patch_ready" off bugzilla.

Committed in 12717 and 12718

Remaining issues split to bug 765.