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.
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. 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. 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. 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. I have played around quite a bit with the memory settings but never really got a perfect setup. 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. --- Mathias Bauer <[EMAIL PROTECTED]> wrote: > Kent Gibson wrote: > > > We render documents using the api. For the most > part > > everything is great but performance. > > > > Are there any ways I can tweak a bit more > peformance? > > Hard to give a specific answer for such a general > question. :-) > > > For example we do not use the database, calc or > > presenation components. Is there any way I can > make > > sure these components are not slowing things down? > > > If you don't use them they will not hurt you. It's > code that is loaded > only on demand. > > > If I built OpenOffice myself, is there anyway I > could > > optimise the build? > > In general I would say yes, but I don't know your > requirements are. > > > The documents we render are read only, is there > any > > way I can make sure that things like UI event > > listeners aren't slowing things down, and if they > are > > how can I avoid this penalty? > > How do you render the documents? And how do you load > them? > Can you point to specific API calls that seem to be > slow? > > 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] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
