cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Arbortext Editor performance

Highlighted
Level 1

Arbortext Editor performance

Adepters:

Our users are asking if there's anything they can do to improve the performance of Arbortext Editor (5.2, patch M130). Their main complaints are the length of time it takes to open a large document and that copy/paste and undo take a long time. I've told them to disable auto-updates of generated text, but was wondering if anyone has other suggestions?

Thanks,
Dave
Tags (2)
11 REPLIES 11

Arbortext Editor performance

I suggest to my writers to collapse any part of the file such as a 
chapter or table not being edited.



On May 29, 2009, at 1:16 PM, "Hintz, David L" 
<-> wrote:

> Adepters:
>
>
>
> Our users are asking if there’s anything they can do to improve the 
> performance of Arbortext Editor (5.2, patch M130).  Their main compl
> aints are the length of time it takes to open a large document and t
> hat copy/paste and undo take a long time.  I’ve told them to disable
>  auto-updates of generated text, but was wondering if anyone has oth
> er suggestions?
>
>
>
> Thanks,
>
> Dave
>
>
>
> ----------

Arbortext Editor performance

Dave,

Check out help 6613, Improving performance for variables used only in specific regions.

Good luck!
Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"


Arbortext Editor performance

Thanks, Suzanne! I should have mentioned that we’re using Styler for the authoring interface, so I don’t know if that help is applicable or how it applies to Styler. I was wondering, though, if performance would improve if I exported Styler to a FOSI and distributed that with the DocType? I wonder if anyone has done any tests comparing Styler performance with FOSI performance strictly for authoring?

Dave

Arbortext Editor performance

I did exactly such research at another job and can confirm that having a screen-only FOSI was better in terms of authoring performance.

Regards,
Jason

Arbortext Editor performance

If the document is table-heavy, you can suppress the graphic display of
tables for a performance boost.

If the custom folder is located on the network (and you have network issues)
or over VPN, you can support a local custom folder on the author's
workstation that can be manually refreshed (or, perhaps refreshed once a
day, week, or on trigger ... depends on how fancy you want to get).

I agree, a screen FOSI would probably be faster than a screen stylersheet,
especially if you edit it down to only the code relevant for screen display.

Arbortext Editor performance

I assume we're talking a hand-crafted screen FOSI right? Because,
behind the scenes, a stylersheet is transformed to a FOSI anyway for
screen display...

-G

Quoting Paul Nagai <->:

> If the document is table-heavy, you can suppress the graphic display of
> tables for a performance boost.
>
> If the custom folder is located on the network (and you have network issues)
> or over VPN, you can support a local custom folder on the author's
> workstation that can be manually refreshed (or, perhaps refreshed once a
> day, week, or on trigger ... depends on how fancy you want to get).
>
> I agree, a screen FOSI would probably be faster than a screen stylersheet,
> especially if you edit it down to only the code relevant for screen display.
>
> On Fri, May 29, 2009 at 2:44 PM, Jason Aiken
> <jaiken@infotrustgroup.com>wrote:
>
>> I did exactly such research at another job and can confirm that having a
>> screen-only FOSI was better in terms of authoring performance.
>>
>>
>>
>> Regards,
>> Jason
>>
>>
>>
>> *From:* Hintz, David L [

Arbortext Editor performance

David,

Are your large documents broken up into fragments? We break our
documents into fragments and encourage authors/editors to work at the
fragment level for most work. They only need to open the master
document occasionally to check their work and view the generated text
content.

Another consideration is how authors and editors are connected to the
source files. All our authoring and editing is done on Windows PCs, our
source library is maintained on Solaris servers. We were using
Hummingbird NFS Maestro to NFS mount the server directories on the PCs;
performance was very slow on larger documents. After some testing, we
switched to Samba connections which have been significantly faster.

Cheers,

David

Arbortext Editor performance

We're using the Contenta CMS, so authors check out individual objects which can be a single topic or an object that is an entire set of topics that compose a book. I'm pretty sure that the performance issues occur when they check out an entire book.

When a CMS object is checked out, it is to the authors local Windows drive. So, there are no network issues involved.

Arbortext Editor performance

I seem to recall hearing a rumor to this effect. It would be nice if someone from Arbortext could confirm or deny this fact. If a Styler stylesheet is always converted to a FOSI (presumably when a doctype is first opened), then it would seem that the only performance gain by using a FOSI in the first place is this brief conversion step.