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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
