thanks for your detailed response. I would like to implement most of your suggestions. Unfortunately, it seems that my bosses have decided against keeping our OpenOffice solution. This could very well be a failure on my part to write optimal code, I don't know.
But while I am on my soapbox, I would just like to say one thing. The thing that puts OpenOffice way ahead of "the competition" is the API. I, and I suspect a lot of possible OpenOffice customers would like to see a faster api. I think the decision to stop using an ODF solution is short sighted, but I can't seem to do much about it. Thanks again for all the help and for creating a very good tool. --- Mathias Bauer <[EMAIL PROTECTED]> wrote: > 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] > > __________________________________________________ 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]
