Empty RVE and Addict Autospell = 100% CPU

General TRichView support forum. Please post your questions here
Marsianin
Posts: 193
Joined: Sun Sep 25, 2005 11:03 pm

Empty RVE and Addict Autospell = 100% CPU

Post by Marsianin »

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?
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

Addict's live spellcheck does not work for TRichView at all.
Use TRichView.OnSpellingCheck event instead.
Marsianin
Posts: 193
Joined: Sun Sep 25, 2005 11:03 pm

Post by Marsianin »

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.
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

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
Posts: 193
Joined: Sun Sep 25, 2005 11:03 pm

Post by Marsianin »

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...
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

I cannot reproduce the problem.
For any case, make sure that you call this method after calling Format.
Marsianin
Posts: 193
Joined: Sun Sep 25, 2005 11:03 pm

Post by Marsianin »

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?
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

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
Posts: 193
Joined: Sun Sep 25, 2005 11:03 pm

Post by Marsianin »

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...
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

I think this method just starts a live spelling thread (if LiveSpellingMode = rvlspOnChange). Although, a code in OnStyleConversion event may be important.
Marsianin
Posts: 193
Joined: Sun Sep 25, 2005 11:03 pm

Post by Marsianin »

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
Posts: 164
Joined: Tue Nov 08, 2011 5:11 pm

Post by JonRobertson »

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.
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

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
Posts: 164
Joined: Tue Nov 08, 2011 5:11 pm

Post by JonRobertson »

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.
Sergey Tkachenko
Site Admin
Posts: 17253
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

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