Apache OpenOffice (AOO) Bugzilla – Issue 104917
framework: each opened and closed document slows a running soffice.bin down
Last modified: 2013-08-07 15:31:14 UTC
The attached documents simulates the behaviour of a batch-processing done by one of our custom applications that is connected via uno-api. Multiple documents are opened, processed and closed again. With each opened document, OOo slows down a little bit more. To reproduce the issue, just open the document openAndClose500textdocuments.odt (allow macro-execution) and press "Open And Close 500 visible Textdocuments" on a linux system. The macro produces output in the textdocument that shows the time required for the processing of each block of 10 textdocuments. On a linux-system, the required time increases noticable. the macro is very simple. Here you can see what the macro does: function openLoop(hidden as boolean, doc) dim args(1) as new com.sun.star.beans.PropertyValue dim lastTimer as long args(0).Name="Hidden" args(0).Value=hidden lastTimer=Timer for i=1 to 500 newdoc = StarDesktop.loadComponentFromURL( "private:factory/swriter", "_blank", 0, args()) newdoc.close(true) ' ...print time required for 10 documents next i End function The macro doesn't slow down OOo on a windows system. So it seems to be a hole in the memory-management on linux.
Created attachment 64643 [details] Document with a macro that simulates the batch-processing
Carsten, please take over
Do you have any extensions installed, perhaps Language Tool? If yes, does the problem go away if you deinstall them?
I removed all extensions (user-specific and shared) and the behaviour is still the same. BTW.: there is now slow down, when you press the second button that opens the documents invisible. Here the output of the test on my linux system without any extensions. Maybe the required times could give a clue of the complexity of the problem. opened 10 documents in 3 seconds opened 10 documents in 3 seconds opened 10 documents in 4 seconds opened 10 documents in 3 seconds opened 10 documents in 4 seconds opened 10 documents in 3 seconds opened 10 documents in 4 seconds opened 10 documents in 3 seconds opened 10 documents in 4 seconds opened 10 documents in 3 seconds opened 10 documents in 4 seconds opened 10 documents in 4 seconds opened 10 documents in 4 seconds opened 10 documents in 4 seconds opened 10 documents in 5 seconds opened 10 documents in 4 seconds opened 10 documents in 5 seconds opened 10 documents in 5 seconds opened 10 documents in 5 seconds opened 10 documents in 6 seconds opened 10 documents in 6 seconds opened 10 documents in 6 seconds opened 10 documents in 6 seconds opened 10 documents in 7 seconds opened 10 documents in 7 seconds opened 10 documents in 8 seconds opened 10 documents in 8 seconds opened 10 documents in 8 seconds opened 10 documents in 9 seconds opened 10 documents in 9 seconds opened 10 documents in 10 seconds opened 10 documents in 11 seconds opened 10 documents in 10 seconds opened 10 documents in 11 seconds opened 10 documents in 12 seconds opened 10 documents in 15 seconds opened 10 documents in 14 seconds opened 10 documents in 14 seconds opened 10 documents in 14 seconds opened 10 documents in 14 seconds opened 10 documents in 15 seconds opened 10 documents in 19 seconds opened 10 documents in 16 seconds opened 10 documents in 17 seconds opened 10 documents in 19 seconds opened 10 documents in 20 seconds opened 10 documents in 21 seconds opened 10 documents in 21 seconds opened 10 documents in 22 seconds opened 10 documents in 23 seconds
cd: It's a complex task to find memory leaks and sometimes you find out that design problem are the root cause. Therefore I don't see how to fix this issue in the OOo 3.3 time line (show stopper phase). Finding and fixing memory leaks is a ongoing task, may be you find out that this problem has been fixed. If you believe that this issue should be handled as a showstopper for OOo3.3 please nominate it accordingly in the releases mailing list.
set target to 3.x since not release relevant for 3.4 release.