Empty RVE and Addict Autospell = 100% CPU

Marsianin · Post by **Marsianin** » Mon Aug 22, 2011 8:27 pm

When Addict4 spell checker is set to autocheck while typing with empty RichViewEdit CPU usage is almost 100%
Typing 1-2 letters in RVE and it became normal.
Is there a way to fix it?

Post by **Sergey Tkachenko** » Tue Aug 23, 2011 9:42 am

Addict's live spellcheck does not work for TRichView at all.
Use TRichView.OnSpellingCheck event instead.

Marsianin · Post by **Marsianin** » Tue Aug 23, 2011 10:27 pm

This is why I'm writing it here and not in addict forums.
I'm using RichViewEdit1.StartLiveSpelling; and running this on empty document produces high CPU usage.
Typing something brings CPU back to normal.

Post by **Sergey Tkachenko** » Wed Aug 24, 2011 1:17 pm

I do not know how it's possible. The live spelling thread must be suspended very quickly for long document. And OnSpellingCheck should not be called even once.
Try to trace TRVWordEnumThread.Execute.

Marsianin · Post by **Marsianin** » Wed Aug 24, 2011 5:40 pm

It's not for long document, it's for empty one.
I'm calling StartLiveSpelling (if enabled in my program's options) every time I clear or load new document into RVE.
And calling it just after creating a new document (clearing previous one) consumes CPU. Empty document, maybe 1 default style, no items...

Post by **Sergey Tkachenko** » Wed Aug 24, 2011 5:58 pm

I cannot reproduce the problem.
For any case, make sure that you call this method after calling Format.

Marsianin · Post by **Marsianin** » Wed Aug 24, 2011 9:47 pm

It happens just after this code (ClearRVE):

Code: Select all

  RichViewEdit1.Clear;
  RVStyle1.TextStyles.Clear;
  with RVStyle1.TextStyles.Add do begin
    FontName:=EditorFontName;
    Size:=EditorFontSize;
    Color:=DefTextColor;
  end;
  RVStyle1.ParaStyles.Clear;
  RVStyle1.ParaStyles.Add;
  RVStyle1.ListStyles.Clear;
  RichViewEdit1.BackgroundStyle:=bsNoBitmap;
  RichViewEdit1.BackgroundBitmap:=nil;
  RichViewEdit1.Color:=EditorDefColor;
  RichViewEdit1.LeftMargin:=3;
  RichViewEdit1.RightMargin:=3;
  RichViewEdit1.TopMargin:=3;
  RichViewEdit1.BottomMargin:=3;
  RichViewEdit1.MinTextWidth:=0;
  RichViewEdit1.MaxTextWidth:=0;
  RichViewEdit1.BiDiMode:=rvbdUnspecified;
  RichViewEdit1.Format;
  FontNameCombo.ItemIndex:=FontNameCombo.Items.IndexOf(EditorFontName);
  FontSizeCombo.Text:=IntToStr(EditorFontSize);
  StylesCombo.ItemIndex:=0;
  RichViewEdit1.ApplyStyleConversion(TEXT_APPLYSTYLE);
  RVRuler1.UpdateRulerIndents;
  RVRuler1.UpdateRulerMargins;
  RVRuler1.AdjustPosition;

If I comment RichViewEdit1.ApplyStyleConversion(TEXT_APPLYSTYLE); it does not consumes CPU. Why?

Post by **Sergey Tkachenko** » Fri Aug 26, 2011 11:28 am

Unfortunately, I cannot reproduce this problem.
May be for some reason TRVWordEnumThread.Execute runs in a cycle instead of suspending itself, but I do not know why it can happen

May be you try to trace this procedure and see how many cycles it makes?

Marsianin · Post by **Marsianin** » Fri Aug 26, 2011 6:59 pm

Looks like something happens just after RichViewEdit1.ApplyStyleConversion(TEXT_APPLYSTYLE) which applies default style to an empty RVE.
Because disabling this code does not consumes CPU.
Anyway I'll try to play more with this...

Post by **Sergey Tkachenko** » Sat Aug 27, 2011 6:03 am

I think this method just starts a live spelling thread (if LiveSpellingMode = rvlspOnChange). Although, a code in OnStyleConversion event may be important.

Marsianin · Post by **Marsianin** » Mon Aug 29, 2011 5:49 am

You're right. Changed LiveSpellingMode to rvlspManualStart and everything works fine without CPU consumption. Anyway I start auto spell checking manually.

But I think it's a bug...

JonRobertson · Post by **JonRobertson** » Thu Jul 05, 2012 9:00 pm

We just implemented LiveSpelling with Addict a couple of days ago and we were seeing this same issue, although our scenario was a little different.

If our TRichViews were empty, we were not seeing a race condition. But if our TRichViews had content (loaded with InsertRVFFromStreamEd), then we'd see a race condition. (I know I shouldn't be using InsertRVFFromStreamEd, but I get Index Out of Range errors if I use other methods and I haven't figure that out yet.)

We have a form that contains multiple TRichViews. In one particular scenario there are four or five TRichViews, each with content. Our app would race all four of the CPUs in my quad-core machine.

I was calling StartLiveSpelling after Format because I read somewhere that was the approach to take. I didn't know about LiveSpellingMode until your post and didn't realize it defaulted to rvlspOnChange.

If I comment out my calls to StartLiveSpelling, the CPU race went away. (And yet I was confused why LiveSpelling was still working, until now

) If I change LiveSpellingMode to rvlspManualStart and leave in my calls to StartLiveSpelling, the CPU race also goes away.

Post by **Sergey Tkachenko** » Fri Jul 06, 2012 11:30 am

The threads may really take a lot of CPU time when working. If CPU does not have other work to do, why not to complete checking ASAP? But they have the lowest priority and I believe they do not slow down other operations too much. Am I right?
After finishing checking, the thread is not deleted but suspended.

JonRobertson · Post by **JonRobertson** » Fri Jul 06, 2012 11:39 am

This isn't what we saw. Our QA team suspected something was wrong because of how slow the form was behaving. This form is a core piece of our new release. The form has been in development for the past month, with new functionality gradually added during that time. QA has been testing the form heavily for the last couple of weeks, while development continues.

QA noticed a couple of days ago that the form suddenly was not as responsive as it was. It was sluggish and operations that previously were instantaneous were taking a couple of seconds at times. The slowness wasn't seen just in the TRichViewEdits, it was seen throughout the app when this form was open.

As I mentioned, the CPU on all four of my processors would race at 99% and would stay there as long as the form was open. The app was not locked up, but performance was impacted.

Once I set LiveSpellingMode to rvlspManualStart on each TRichViewEdit, the CPU was no longer racing and our performance returned to how it was.

This isn't the impact of the work that LiveSpelling is "supposed" to do. LiveSpelling is working for us and it works fairly quickly (these TRichViewEdits have very little content). This is a thread race condition that is abnormal.

If it is important to you, I can spend some time trying to determine what TRVWordEnumThread is doing to cause the CPU to race at 99%. But it'll be a few days before I can spend additional time on it.

Post by **Sergey Tkachenko** » Fri Jul 06, 2012 6:55 pm

I have a guess.
We recently found a bug: if StartLiveSpelling is called (almost) immediately after some editing operation (or an editing method), and this editing operation already started a live spelling (it happens if LiveSpellingMode=rvlspOnChange), then StartLiveSpelling does not restart checking, but puts the thread in a waste cycle.

As a quick fix you can either change LiveSpellingMode or do not call StartLiveSpelling.
We plan to upload a fixed version in the next week.