Re: rvoFastFormatting sometimes not so fast

Author

Message

Louis Kessler

Posted: 06/12/2005 23:54:03

Just a suggestion. Try using a profiler to isolate what exact routines are

taking the extra time. I have done this in the past to isolate the "slow"

parts of TRichView to speed it up for large documents. There are usually only

a few bad lines that take 90% of the time, and they can often can be replaced

or improved.

There are many good profilers available for free. I use gpprofile at

http://17slon.com/gp/gpprofile/

In your case, you might want to run the profiler with rvoFastFormatting off,

and then run it again with rvoFastFormatting on. That should tell you a lot.

Louis Kessler

Winnipeg, Manitoba, Canada

Website: www.lkessler.com

---- Original Message ----

From: "David Novo" <[email protected]>

Newsgroups: trichview.support

Sent: Sunday, June 12, 2005 1:40 PM

Subject: Re: rvoFastFormatting sometimes not so fast

> Hi Rob,

> Let me explain my situation in a bit more detail. I can send you a

> compiled version of the program with the option turned on and off, and

> you will see it takes about 4x longer to load with rvoFastFormatting

> turned on.

> Let me explain my situation in a bit more detail to see if this

> triggers something. Imagine my application like MS powerpoint. You can

> have different slides, and put as many text boxes as you like on a

> slide. I use one style object per document, and share the style among

> the different richviews. (Thanks to Sergey for recently adding the

> capability to delete unused styles when the style object is shared).

> I used to create one richview per textbox, therefore for this persons

> document, there would be 600 richviews open when the document was

> loaded. This was an incredible drain on system resources. I have

> recently modified it so that when a text box becomes visible, it

> requests a richview from a cache that I have. When it becomes

> invisible (i.e. the user switches to a different page), the richview

> is returned to the cache.

> When loading, it loads the RVF from a stream each textbox, formats it

> to make sure that everything is okay, and then saves the RVF to a

> temporary stream and returns the richview to the cache. This happens

> about 600x. With rvoFastFormatting on, this takes about 4 minutes.

> With rvoFastFormatting off, this takes about 1 minute. (note, there

> are many other objects aside from richview in the document, so

> richview is not taking all the time, however, it is responsible for

> the increase from 1-4 minutes).

> My suspicion is a bulk of the time is being take requesting resources

> from windows. The document is 55 pages long. Each page has roughly the

> same number of objects on it. But the first few pages go by very

> quickly, and you can see that it takes longer and longer as more pages

> are loaded. So, from what I gleaned from the newsgroup, you are

> requesting a GDI object for each item, to calculate a textwidth or

> something. Could it be the thousands of GDI objects that I am

> requesting and returning when each richview is requested, then

> returned, to the cache is slowing things down?