Hangs for a long time when editing labels on large files

* JC: The algorithm for sorting/arranging the labels is being called
frequently, isn't particularly efficient and is probably being called at times
when it doesn't need to be. There are probably some changes that can be done
quickly that will make 1,000 labels tolerable.

* GA: PX at present. I have not tried on Windows yet. Have asked Steve if he
tested on Linux, which makes all the reports on Linux so far. OP said there was
not a problem on one 32-bit machine, so I asked what version of Audacity that
was.

Although we can do damage limitation to make 1000 labels more usable, I agree
with Steve that "labels" are just that. We should develop a proposal to make
labels more like a text editor (and maybe link with a real one). This will
solve other problems like "can't add text to labels when reach end of the
project", "no multi-line label support", "no search within labels"

I've just tried this under Windows XP (with 1.3.12) without a problem. I
created a 40 minute chirp track with 1024 labels - mostly just the numbers
1,2,3..8, but a few labels had actual text. I was able to apply effects like
fade out without problem.

Editing of labels was a bit sluggish. I type 'Hello' in a label and the
letters take about 3 seconds to appear, but acceptable at this stage of
development.

Looking at the code, sort() is only likely to be problematic when dragging a
label. For the reported problem it would more likely be OverGlyph() that is at
fault.

If a developer on Linux sees this problem it would help if they interrupt the
process when it is going real slow and see what function is in the call stack.
If it is OverGlyph() converting that from a linear search to a binary search as
per comment above it would help.

A separate enhancement request for integration with a real editor would be
good. I agree that we're not trying to support complete novels in each label.
About 10 words in each is reasonable. I see no reason though that we should
not support 10,000+ labels. In any case we would need large numbers of labels
to support the real editor, since Audacity rather than the editor would still
manage the time intervals.

Support for line breaking in labels would also be a nice but very very low
priority enhancement.

Steve confirmed he was testing on Linux. Can someone test on Mac? That might
push it to a P2 if it's a problem there as well.

I think enhancements should be a Wiki proposal at this stage. Perhaps it should
be called "Better transcription support" to match with the Feature Requests
about it. I think there is a good use case and the Feature Requests page
probably understates the level of interest (for example, people transcribing
audio books for the blind often use Audacity). So while we should handle many
short labels, the enhancement is to provide a better environment for working
with long section-level labels.

A report on launchpad forwarded by Benjamin:
https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/529337

suggests EXPERIMENTAL_LYRICS_WINDOW is to blame. Since this feature uses the
first label track, you can work around the bug by inserting a bogus empty label
track before the one that you actually want to edit.

Devel-fixed Rev:10931
(if valid fix, this bug therefore converted to a P4 on Lyrics Window).

This bug was caused by AudacityProject::UpdateLyrics() recreating its copy of
the lyrics completely, even when the window was not in use. Expensive because
it removes and adds the labels all over again one at a time.

The update postpones this step until the lyrics window is made visible.

Of course if you edit the labels or make other changes whilst the lyrics window
is open and there are a large number of labels, it will still be very slow, but
the bug no longer affects normal use of large numbers of labels.

---bug demoted---

I've demoted the remaining part of the bug to a P4, and changed the title from:

Excessive delay/CPU usage performing actions in projects with several hundred
labels

to

Lyrics Window makes things slow, when many labels.

Because the slowdown now only happens if the window is visible.

Thanks James. Works fine on Windows. The additional delay now only occurs when
the Karaoke window is open, but the delay was only ever a second or two as far
as I can tell.

However on Linux even opening the karaoke window (which I think people could
well do) takes up to 10 minutes when there are 1000 labels. Given that and the
severity (editing one label can then take half an hour) I think it should
remain release noted (for Linux). Promoted back to P3.

This commit: https://github.com/audacity/audacity/commit/376fc0ebf294ca39b56f0ef4177a995f2de11f26

Does not fix every inefficiency, but I think I found and fixed the grossest problem, at least as it runs on Windows.

Details:

Lyrics::mHighlightTextCtrl is there to implement a different mode in which the Lyrics window displays multiple lines, but the code making the radio button to enable this mode is commented out. Yet, there is code updating this invisible text control, and that seems to be eating most of the time up:

  int nTextLen = mSyllables[i].textWithSpace.Length();
  if ((nTextLen > 0) && (mSyllables[i].textWithSpace.Right(1) == wxT("_")))
     mHighlightTextCtrl->AppendText(mSyllables[i].textWithSpace.Left(nTextLen - 1) + wxT("\n"));
    else
      mHighlightTextCtrl->AppendText(mSyllables[i].textWithSpace);

... and the many AppendText() calls (one for each label) each cause processing of an event, at least in the Windows implementation of wxTextCtrl.

Commenting out the above lines fixes most of the delay.

But rather than do that, which might be best for speed, I just rewrite things to compose one big string and then call AppendText once, and edits are then tolerably fast. Maybe somebody wants to reenable mHighlightTextCtrl some day?

Adding Gale, the Reporter, to CC.

I claim fix made.

Testing on W10 on audacity-win-r376fc0e-2.1.3-alpha-22-jan-16

I cant reproduce this using Steve's "Steps to reproduce" in this bug report - so therefore assume fixed.

BUT I can't reproduce this on 2.1.0, 2.1.1 or 2.1.2 either

Peter, it was only a significant problem on Linux. See Gale's comment #5

I disagree that it was significant only on Linux. It just might need more labels to be evident on recent fast machines. I know I made it happen on Windows and fixed a noticeable delay.

Generate a click track, 300 beats per minute, duration 10 minutes.

Use Sound Finder, with second, third, and fourth sliders pushed all the way left.

Now you have 3000 labels.

Click in one and type characters. Updates are immediate.

Open Karaoke and try it again. On my computer, now I see noticeable delays after each keystroke.

Testing on Mac El Capitan on 01a95c5-2.1.3-alpha-13-feb-16
and
Testing on W10 on aud audacity-win-rf933621-2.1.3-alpha-19-feb-16

Using Paul's test methodology with 3,000 labels 10 minute track from Comment #11

I have no noticeable delays on either of my machines (both fast machines) either with or without Karaoke running

Thanks, Paul. RESOLVED-FIXED but see my comment at the end about CPU use in case it is important.

Yes with 3000 labels on Win 7 64-bit (2.4 GHz) I see the difference between 2.1.2 release and HEAD when Karaoke is open.

Tested on Ubuntu 14.04 32-bit (Atom 1 GHz processor) with 1500 labels. In 2.1.2 release it took 15 minutes to get the Karaoke window open, then 5 minutes to produce a single character in a label. In HEAD, Karaoke window pops up almost at once and it takes a couple of seconds to type a character in a label. Effects are responsive. On that machine in HEAD, CPU use when typing a character in a label is 75% without Karaoke open and 100% when Karaoke is open, but only a short burst at 100% compared to 5 minutes at 100% is 2.1.2.

The comparable CPU usage on the Win 7 machine looks like 25% and 35% respectively (about 8% when Audacity is idle). The usage seems quite expensive (to me) considering typing a label currently doesn't write to the .autosave file.

Perhaps, then, this bug should be left open but with less priority until further performance improvements can be found?

(In reply to Paul L from comment #14)
> Perhaps, then, this bug should be left open but with less priority until
> further performance improvements can be found?
Is it this bug or a more general one that typing in a label is too CPU expensive?

On the 1 GHz machine typing a character into one of 1500 labels takes 75% even with Karaoke closed. It takes 65% even with one label, but with one label there is no performance impact. With 1500 labels, no Karaoke, 75% usage, it takes 1 second for the typed character to appear. With 1500 labels, karaoke, 100% usage, it takes 2 seconds for the typed character to appear.

There is an old resolved bug 406 for label (and other) slowness where I think the only changes made were to reduce the amount of autosaving. However that alone made a dramatic improvement. It looks like redrawing less of the track panel was not attempted.

I note that typing a character in an almost empty text document produces a 90% spike on the 1 GHz machine. So perhaps this is not really anything to worry about.

What do you think?