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

Improving performance in Epic 5.1

mark.cole
1-Newbie

Improving performance in Epic 5.1

Hi Adepters,




I was wondering if anyone had any ideas / tips for improving the performance of Epic when working with large documents / tables?



Regards,




Mark Cole


Application Developer


Jane's Information Group


( +44 (0)20 8700 3976


7 +44 (0)20 8700 3900


*<u></u><u> Mark.Cole@janes.com</u>




Disclaimer: This e-mail, its content and any file attachments are confidential and may be legally privileged. If you have received this e-mail in error, please do not copy, disclose it to any third party or use the contents or attachments in any way. Please destroy it and contact +44 (0)20 8700 3700, +1 (703) 683 3700 or e-mail info@janes.com. Whilst we check the communications we send for virus infection, we accept no responsibility for any loss or damage caused to your systems by the communication you receive. This e-mail or its attachments may contain personal views which are not the views of Jane's Information Group unless specifically stated.

14 REPLIES 14

I manually comment out the tables or parts of tables I'm not interested
in, using a text editor. That way only the ones I want to work on need
to open.



>>> mark.cole@janes.com 02/08/06 12:19PM >>>

Hi Adepters,
I was wondering if anyone had any ideas / tips for improving the
performance of Epic when working with large documents / tables?
Regards,
Mark Cole
Application Developer
Jane's Information Group
( +44 (0)20 8700 3976
7 +44 (0)20 8700 3900
* Mark.Cole@janes.com
Disclaimer: This e-mail, its content and any file attachments are
confidential and may be legally privileged. If you have received this
e-mail in error, please do not copy, disclose it to any third party or
use the contents or attachments in any way. Please destroy it and
contact +44 (0)20 8700 3700, +1 (703) 683 3700 or e-mail info@janes.com.
Whilst we check the communications we send for virus infection, we
accept no responsibility for any loss or damage caused to your systems
by the communication you receive. This e-mail or its attachments may
contain personal views which are not the views of Jane's Information
Group unless specifically stated.>> To unsubscribe from the list, send
an email to listmanager@maillist.arbortext.com with the following in the
body: unsubscribe adepters - For additional information on the adepters
list (how to subscribe or unsubscribe etc), send an email to:
listmanager@maillist.arbortext.com with the following in the body:
info Adepters - You may also go to forums.arbortext.com, enter the
Adepters folder and change your subscription options and preferences.>>


Mark,



Are you working with the large document
(I'll get to tables in a minute) for editing or publication? If you
are editing, there are several ways to improve the performance, probably
the best is to try to modularize the document. Make chapters (or
similar blocks) individual files. Only bring all the pieces together
for publication (or a QA prior to publishing).




You can use the DTD Fragment to do this.
The markup resembles this







The Fragment has to be inside a comment as does the DOCTYPE declaration
AND (repeat AND) so do any locally declared ENTITIES in the declaration
subset. Epic will then interpret the document making believe any
missing parent elements are present. The DTD fragment is an OASIS
TR and not an Arbortext extension like the PI




Pub
CX milstd(front()body(
>



Though Epic will insert one that emulates the path you are currently in.




By editing a smaller chunk of you document,
Epic does not have to parse, assign OIDs, generate text, etc for the entire
document and it will run faster.




Now on to Ed's "Spawns of Satan"
tables. You could modularize your tables to be file entities as well
and edit them with the DTD fragment as well. However, if you have
an extremely large table, you may not be able to improve your performance
and breaking a table down is not something for the faint hearted I
would not try it.




Lynn

Turn off automatic update of generated text, especially if your
paragraphs or steps are counted and have the paragraph or step number
displayed by the screen FOSI.

In addition to separating the tables out into entities I would also suggest working the table elements in markup mode versus image mode. Writers struggle with the view at first however are sold on the response performance.

Lupe Babcock
661.265.3320
guadalupe.v.babcock@boeing.com

face="Comic Sans MS" color=#800000 size=2>Lynn, Ed, Lupe,

face="Comic Sans MS" color=#800000 size=2>

face="Comic Sans MS" color=#800000 size=2>Our books are divided up by
Chapter,section and then each record in that section is an individual XML
document. We use Content@ as our XML repositoryand we tried in the
past to split the document up into entities but this was unpopular with our
users becausethey preferred to see the whole record they were working on
while editing and were also unable to manipulate the record the way they
wanted. Basically, they didn't have much flexibility in deciding what
order these entities would go in inside the record.

face="Comic Sans MS" color=#800000 size=2>

face="Comic Sans MS" color=#800000 size=2>We also have some books that are just
packed with tables, very large ones too. I would turn off automatic update
of generated text as Ed suggests but our users like to insert numbered notes in
our tables and link them to data in the table. In the past they have
kicked up a stink because the numbers weren't in sync (because generated text
was not updated automatically), they don't like the extra work of having to
click one more button on the toolbar. Finally, thank you Lupe for
suggestion but I also don't thinkmy userswill like the idea of
switching the tables into markup mode. They complain enough already about
how tables are displayed in Epic. This will just give them one more reason
to moan.

face="Comic Sans MS" color=#800000 size=2>

face="Comic Sans MS" color=#800000 size=2>Regards,

face="Comic Sans MS" color=#800000 size=2>Mark





From: Lynn Hales

Sent: 08 February 2006 18:36
To:
adepters@arbortext.com
Subject: Re: Improving performance in Epic
5.1



Mark,

face=sans-serif size=2>Are you working with the large document (I'll get to
tables in a minute) for editing or publication? If you are editing, there
are several ways to improve the performance, probably the best is to try to
modularize the document. Make chapters (or similar blocks) individual
files. Only bring all the pieces together for publication (or a QA prior
to publishing).


You can use
the DTD Fragment to do this. The markup resembles this

face="OEM Fixed" color=#000080 size=2>

The Fragment has to be
inside a comment as does the DOCTYPE declaration AND (repeat AND) so do any
locally declared ENTITIES in the declaration subset. Epic will then
interpret the document making believe any missing parent elements are present.
The DTD fragment is an OASIS TR and not an Arbortext extension like the
PI


Pub CX
milstd(front()body(
>


Though Epic will insert one that emulates
the path you are currently in.


By
editing a smaller chunk of you document, Epic does not have to parse, assign
OIDs, generate text, etc for the entire document and it will run faster.



Now on to Ed's "Spawns of Satan" tables.
You could modularize your tables to be file entities as well and edit them
with the DTD fragment as well. However, if you have an extremely large
table, you may not be able to improve your performance and breaking a table down
is not something for the faint hearted I would not try it.



Lynn

Have
you asked them if they want some cheese with their whine?




Sounds like the users want their cake
and eat it too. Give them the choices performance or status quo.
They are the problem. As Pogo once said,




"We have met the enemy and he is
us."



Lynn

Just dreaming out-of-the-box, along the lines of "All problems in computer science can be solved by another level of indirection".

Your users seem to be a bit fixated on the final rendering; but actually, maintaining large tables and complex annotations in the final rendering form might be error-prone and inefficient.

Maybe there is an underlying information model behind the content in those very large tables?

Maybe the content of those very large tables are better maintained using some other tool or mechanism?

Maybe the content of the tables can also be represented in a less costly content model (for subsequent transformation into table markup)?

Maybe references and annotations can be maintained out-of-band?

Kind regards
Peter Ring

I'm just being cynical here, but it looks like most of your proposed
solutions would require that the users click extra buttons (at the very
least) and therefore would be unacceptable. Perhaps telepathic software
that reads the mind of the user and knows what he/she *wants* to do, as
opposed to what he/she actually typed. In fact, typing would not even
be needed. They could just use the Professor Harold Hill "think
system".


Only yesterday I was asked to create a button that "turns the green text
into normal text". These are the kind of absurd requests I have to put
up with every day!

The buttons on the keyboard, actually.

Well aware that there are no easy answers, I'm asking questions, not proposing solutions.

How do these footnotes contribute value for the end users of the documents?

Is it crucial for this value-add that someone click cute buttons in order to insert markup in the documents?

Could input to the process be created in other ways?

Let me illustrate the point with an example:

We have a large collection of documents that are annotated with in-stream indexterm elements. Maintaining the index is a royal PITA if you need to edit the source documents, e.g., index terms are added after-the-fact by a separate index author. We are migrating the in-stream indexterm elements out of the documents, and we use a simple spreadsheet format for exchange.

kind regards
Peter Ring

I was just yanking your chain, Peter. Previous posts on this subject
(especially mine) had made disparaging remarks about the users' desire
for effort-free editing.

OK 🙂

I've also been a (bastard) sysadmin (from hell) and know about evil, ignorant and lame users. But in general, I think, most people actually make a best effort. It's just that they don't know what they are really contributing, how they affect the (work-)life of other people, and what the alternatives are. So they tend to sub-optimize their own little turf. When they get to know the big picture, they start whining about what's really important, rather than petty hobbyhorses.

kind regards
Peter Ring

id=role_document face=Arial color=#000000 size=2>

Mark,


IF you can set hidesuppressed=on,I think the following should help.
You could code the screen FOSI to suppress a table when an ati:display attribute
is set to no. You would need to provide a menu item, toolbar icon, and/or
keymapping for authors to turn table display on and off. The screen FOSI would
display a message about how to toggle table display. It's an extra click for the
authors, but gentext update could still be set to full. (Standard disclaimer
here.)


Good luck!

Suzanne Napoleon




In a message dated 2/9/2006 11:51:21 A.M. Eastern Standard Time,
mark.cole@janes.com writes:

style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>
face="Comic Sans MS" color=#800000 size=2>Lynn, Ed, Lupe,

face="Comic Sans MS" color=#800000 size=2>

face="Comic Sans MS" color=#800000 size=2>Our books are divided up by
Chapter,section and then each record in that section is an individual
XML document. We use Content@ as our XML repositoryand we tried in
the past to split the document up into entities but this was unpopular with
our users becausethey preferred to see the whole record they were
working on while editing and were also unable to manipulate the record the way
they wanted. Basically, they didn't have much flexibility in deciding
what order these entities would go in inside the record.

face="Comic Sans MS" color=#800000 size=2>

face="Comic Sans MS" color=#800000 size=2>We also have some books that are
just packed with tables, very large ones too. I would turn off automatic
update of generated text as Ed suggests but our users like to insert numbered
notes in our tables and link them to data in the table. In the past they
have kicked up a stink because the numbers weren't in sync (because generated
text was not updated automatically), they don't like the extra work of having
to click one more button on the toolbar. Finally, thank you Lupe for
suggestion but I also don't thinkmy userswill like the idea of
switching the tables into markup mode. They complain enough already
about how tables are displayed in Epic. This will just give them one
more reason to moan.

face="Comic Sans MS" color=#800000 size=2>

face="Comic Sans MS" color=#800000 size=2>Regards,

face="Comic Sans MS" color=#800000 size=2>Mark





From: Lynn Hales

Sent: 08 February 2006 18:36
To:
adepters@arbortext.com
Subject: Re: Improving performance in Epic
5.1



Mark,

Are you working with the large document (I'll get to
tables in a minute) for editing or publication? If you are editing,
there are several ways to improve the performance, probably the best is to try
to modularize the document. Make chapters (or similar blocks) individual
files. Only bring all the pieces together for publication (or a QA prior
to publishing).

You can use
the DTD Fragment to do this. The markup resembles
this



The Fragment has to be inside a comment as does the
DOCTYPE declaration AND (repeat AND) so do any locally declared ENTITIES in
the declaration subset. Epic will then interpret the document making
believe any missing parent elements are present. The DTD fragment is an
OASIS TR and not an Arbortext extension like the PI


face="OEM Fixed" size=2>Pub CX milstd(front()body(>

Though Epic will insert one that emulates the path you are
currently in.


By editing a smaller
chunk of you document, Epic does not have to parse, assign OIDs, generate
text, etc for the entire document and it will run faster.


Now on to Ed's "Spawns of Satan" tables. You
could modularize your tables to be file entities as well and edit them with
the DTD fragment as well. However, if you have an extremely large table,
you may not be able to improve your performance and breaking a table down is
not something for the faint hearted I would not try it.


Lynn
Announcements