Re: [api-dev] Tweaking the api for performance
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
Re: [api-dev] Tweaking the api for performance
Kent Gibson wrote: 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. a fast API is always highly appreciated but often the underlying architecture prevent this. Or it is a compromise between a fine grained API which allows modification on detailed level and|or more high level APIs covering the most often used features. In case of our API we have furthermore the flexibility of language independence which can be a performance barrier as well (i hope it is not to much). I can only say that we try our best to find the best solution for OpenOffice.org in the future and that we have performance on our radar as well as usability. I hope you have more luck on your next project with OpenOffice.org and that we can support you in all API related questions Juergen 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
Re: [api-dev] Tweaking the api for performance
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]
[api-dev] Tweaking the api for performance
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? 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 I built OpenOffice myself, is there anyway I could optimise the build? 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? If it helps our target operating system is windows. thanks kent gibson __ 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]
Re: [api-dev] Tweaking the api for performance
Hi kent did you have a oook at lockControllers and unlockControllers ? http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XModel.html#lockControllers Laurent -- Laurent Godard [EMAIL PROTECTED] - Ingénierie OpenOffice.org - http://www.indesko.com Nuxeo Enterprise Content Management http://www.nuxeo.com - http://www.nuxeo.org Livre Programmation OpenOffice.org, Eyrolles 2004-2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Tweaking the api for performance
thanks. I have tried that. But 1) I noticed no difference (should there a big gain?) and 2) sometimes even though I render in a read only document the results are not the same. I can remember that x,y results from my view cursor sometimes looked odd. I should probably test this again, before I has to do some tricks with selection and that probably confused it. --- Laurent Godard [EMAIL PROTECTED] wrote: Hi kent did you have a oook at lockControllers and unlockControllers ? http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XModel.html#lockControllers Laurent -- Laurent Godard [EMAIL PROTECTED] - Ingénierie OpenOffice.org - http://www.indesko.com Nuxeo Enterprise Content Management http://www.nuxeo.com - http://www.nuxeo.org Livre Programmation OpenOffice.org, Eyrolles 2004-2006 - 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]
Re: [api-dev] Tweaking the api for performance
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]
