TDBRichviewEdit Performance Question

[msimmons15]

I have recently upgraded from version 12 to 14 and I have noticed that performance is slower using TDBRichviewEdit.

I looked at my database blob fields and I noticed that I have some records where the text is NOT compressed (text begins with '{\rtf...' and I have other records where the text is compressed and I see the blob field starting with '-8 1 3-'.

The compressed blobs load almost instantaneously.

The '{\rtf' blobs have a long delay. Eve when I have a record with just a single sentence in it. The text below is quite slow to load even though it is quite short. Any ideas?

{\rtf1\ansi\deff0{\fonttbl{\f0\fnil MS Sans Serif;}}
\viewkind4\uc1\pard\lang1033\f0\fs16 How is bi-directional traceability of all requirements and associated work products maintained?\par
\par}

Thanks,
Mike Simmons
[/img]

[Sergey Tkachenko]

"-8 1 3" indicates RVF (RichView format) documents.

While RTF loading is slower than RVF, but sorry, I do not know the reason why so tiny documents are loaded slowly
I am sure that the actual loading of this field (time of execution of LoadRTFFromStream) is lightening fast, the delay may be caused by some other DB code, not related to TRichView directly.

[msimmons15]

I discovered what the delay was. There is an "Abort" statement being executed at line 6193 of CRVData.pas when the database field content is not a RVF. The actual delay was due to Eurekalog doing processing. Once I disabled Eurekalog, the delay went away.

But I wanted to ask if reaching this abort is an acceptable error? Or should I be doing something differently? I can send you an image of the code, but it is at line 6193 above. The actual IF statement is:

if not RVFReadHeader(Self, CurrentLine, Header, AParaNo,
Color, Background, PTextStylesMapping^, PParaStylesMapping^,
AllowReplaceStyles) then
abort; {error}

[Sergey Tkachenko]

Yes, TDBRichView tries to load RVF, then RTF, then plain text.
For reading RVF, it does not perform any checking, just calls LoadRVFFromStream, and checks if it returns True of False.
If the field does not contain a valid RVF, LoadRVFFromStream quickly returns False.
But yes, LoadRVFFromStream raises a handled "abort" exception when it finds incorrect RVF data.

Ok, I will change the code that loads data.
It will start from checking for RTF header. If found, the component will not attempt to load RVF.
Under normal circumstances, the result will not be faster than the current code. However, "abort" will not be raised in this way.

[msimmons15]

That will help. Thanks!

[msimmons15]

Hi Sergey

It appears the change you planned to do in your March 3, 2014 post was never done. I'm still seeing the same Abort statement and I'm still getting a very long delay as Eurekalog processes the abort.

I will have to see how to disable error processing of "abort" statements in Eurekalog. I think there are about 17 different aborts in CRVData.pas but the one that I hit is in InsertRVFFromStream_. The code is;

if not RVFReadHeader(Self, CurrentLine, Header, AParaNo, Color,
Background, PTextStylesMapping^, PParaStylesMapping^,
AllowReplaceStyles) then
abort; {error}

Mike Simmons

[msimmons15]

Sergey - It seems that Eurekalog processing is creating this long delay. I discovered an option in it that I had to adjust. Once I did that, performance was normal again. So I have no problems at this point. Please ignore my previous email.

Thanks,
Mike Simmons

[Sergey Tkachenko]

However, this change was made.
The new version checks for RTF header first, and attempts to load RVF only if RTF header is not found.