Large documents and Epic Performance...

[myong.song]

Adepters is there any thing I can do improve the performance of Epic 5.1
for large documents? We're just dragging on documents in the 300K range
(and I don't consider this document as being large!). I originally
thought the slowness was due to our extensive .NET customization of
Epic, but just noticed that even without our customization, Epic is just
plain slow. Loading documents of this size take a minute or longer.

I've search and read other posts, but breaking the document down to
different files is something we would like to avoid as much as possible.
Any other ideas? Our users are complaining....Thank you.

-Gerald.

[myong.song]

Adepters, It's our StylerSheet. I guess we should provide a "Normal"
view Stylersheet the user can switch to when working on larger docs.
Thanks.

[ptc-1787870]

So are you going to supply a separate Stylersheet with a more minimized
set of rules for the purpose of authoring?

Supplying a .style stylersheet for this purpose sounds contrary to what
Styler promises--a single source for your style. While Styler can save a
lot of time in development, I've also found that Styler's stylesheets can
cause a hit on performance in the authoring environment. That said, Styler
is only getting better and better with each release and has some really
cool features, including providing the ability for a larger user base to
get in and apply style to an Arbortext environment.

In my experience, however, there's significantly better results when using
a screen FOSI for authoring. It largely depends from project to
project--one could also argue that smaller information chunks, fewer
elements, and other methods to speed up Editor performance could improve
results as well. (Search the archives for posts to this list on how to
improve performance in the Editor using other methods, too. For example,
you can suppress the generated text updates. Note that some of these
methods may degrade usability.)

Regards,
Jason "FOSI farnarkeler | obstreperous curmudgeon | Luddite" Aiken




"Song, Myong S. \(Gerald\)" <myong.song@jicpac.pacom.mil>
10/20/2006 03:27 PM
Please respond to
<adepters@arbortext.com>


To
<adepters@arbortext.com>
cc

Subject

[naglists]

> I've search and read other posts, but breaking the document down to
> different files is something we would like to avoid as much as possible.
> Any other ideas? Our users are complaining....Thank you.

In addition to making sure your screen stylesheet doesn't do more
processing than necessary and possibly turning off gentext, you can
look into turning on table tag display which (somewhat
counter-intuitively) disables the graphic display of tables in Editor.
This will obviously only help if you have many and/or large tables.

Oh, and, uh, more RAM. Say that one twice.

[myong.song]

> From: Jason.Aiken@jeppesen.com
>[...]
>
> So are you going to supply a separate Stylersheet with a more
> minimized set of rules for the purpose of authoring?
>

Yes. I noticed a lot of the slowness is coming from our heavy duty XPATH
expressions used with our FOSI overrides. They tend to be "nice to
have's". Besides our users can create HTML/PDF previews if they wish to
see the generated text that the Stylersheet provided when editing in
Epic.


> [...]
> In my experience, however, there's significantly better
> results when using a screen FOSI for authoring. It largely
> depends from project to project--one could also argue that
> smaller information chunks, fewer elements, and other methods
> to speed up Editor performance could improve results as well.
> (Search the archives for posts to this list on how to improve
> performance in the Editor using other methods, too. For
> example, you can suppress the generated text updates. Note
> that some of these methods may degrade usability.)
>
> Regards,
> Jason "FOSI farnarkeler | obstreperous curmudgeon | Luddite" Aiken
>

Yeah, I set gentext=off and the application is zippy, but it would make
our application unusable. Thanks for all your inputs. We'll examine the
option of FOSI strictly for authoring purposes only for our later
releases. We just don't have any FOSI experts in-house at the moment.
Gerald.