Kent Gibson wrote:
There is no loading, we render each document from
scratch and always keep the result in memory. It
is
hard to pinpoint our bottlenecks. There is not one
particular place. However for example, inserting
into
the document and stlying each cell of a table are
pretty costly operations.
Our table API isn't very fast, that's true. We are
currently working on
a simplified API to insert tables that allows to
hand over attributes
for a larger bunch of cells or rows in one step. If
that was possible in
your case you could save some time here. It should
especially speed up
insertion of simple nxm-tables (n rows with m
columns) without any
subtables or rowspans.
I don't expect this new API and its implementation
to be ready before
the 2.2 release but perhaps it's interesting for you
to know that
something happens here. If you want you can use one
of our developer
builds for testing as soon as we have one that
contains this new API.
Just last week the biggest problem was with
frames. We
rely heavily on frames. After I inserted into the
doument say over a hundered frames I noticed a
severe
slow down, as if a memory leak. However I followed
Laurent Godard advice (thanks) and ensured the
controllers were locked and this problem is now
insignificant. But generally we would like to
still
boost overall performance if possible.
If your frames aren't anchored at the page (what
usually is the case) we
have another bottleneck in the rendering code if you
have a lot of
frames on one page (>100!). But currently we
consider this to be a bit
exotic. We applied some optimizations for this case
though (forgot
wether it will be in 2.1 or not).
This is is our setup: we have a tables, with
frames
inside the tables, anchored to the paragraphs.
Inside
these frames can be tables, text or images. To try
and
avoid round trips to the api we call macros which
create frames ( and page styles) . These macros
sometimes also insert the frame into the document.
Are you sure that your API roundtrip (I assume that
you talk about
remote calls) is really slower than a macro? Our
Basic is not famous for
being the fastest on earth. Just a thought. At
least a small benchmark
is recommended.
Alternatively you could try C++ code instead of
macros and place it into
the OOo process as an extension (a service you can
call). This should
create the least possible overhead. Even
implementing this service in
Java could be an idea; OOo instantiates Java
extensions in its own
process. So while you still have a Java UNO bridge
between the Java code
and the OOo API it will be not interprocess call.
These almost always return the XTextFrame. We also
use
frame styles. Furthermore all text has a character
style and a paragraph style associated with it.
Perhaps you could save some time in making the most
often used styles
the default one of your document. It would save you
setting them explicitly.
The idea to do more processing with macros, so
that
there is less roundtripping sometimes works and
sometimes doesn't. The problem is that for example
sometimes I send all of the content for a table
and
try to let the macro do all the formatting, and it
often works ok, but sometimes I get funny side
effects
as if it is working too fast?! As soon as I switch
back to an algorithmn that uses less macros and
more
api, the results are more consistent.
I also still sometimes get funny side effects with
images. Sometimes I can render a document and the
image does not get scaled correctly. I render the
same
exact document without changing anything and it
gets
rendered ok.
Some API calls might require some formatting that
happens in the
background. Other API calls relying on this should
produce correct
results by forcing pending updates if necessary but
I can't exclude that
this doesn't happen always. Perhaps this could
explain some of your
"funny" problems. Did you try to force layout
updates before doing
"critical" calls?
I have played around quite a bit with the memory
settings but never really got a perfect setup.
The effect of the memory settings on performance on
decent computers is
heavily overrated. ;-)
With the peformance gain from locking the
controllers
I reckon if I could squeeze another 25% somewhere
I
would be very satisfied. But I am not sure how to
do
it. I would hate to waste a lot of time trying to
build OpenOffice and see no gain.
The problem is that a real helpful tip isn't
possible without knowing
exactly which operations are the most painful for
you (from a
performance perspective). I tried to address the few
points you
mentioned, perhaps there's something useful in it.
Best regards,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework
Project Lead
Please reply to the list only, [EMAIL PROTECTED]
is a spam sink.
