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?
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 > > > > ----------
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?
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.
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...
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 > <firstname.lastname@example.org>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 [
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
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.
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.