Apache OpenOffice (AOO) Bugzilla – Issue 57008
performance: Slow saving and loading as ODF
Last modified: 2013-08-07 14:44:00 UTC
Got the sdw file provided in Issue 54338 loaded on the latest release of OO2. 1. Saving it as ODF takes a very long time (not acceptable). 2. Saving it as sdw stucks (or looping). Tried about 8 hours, nothing happened. BTW: Is there any quality assurance regarding the new releases (i found a lot of bugs in the released OO2 version)!!!!!! Why do i provide a file for testing and (nearly) nothing happens.
Reassigned to ES.
Reassigned to HI.
Wrong reassignment, sorryy!
Can reproduce with OOo 2.0.1rc3 WinXP SP2 I can't save as ODF, as this type is not available here (should be?) in Writer. When I try to save as SDW Writer hangs. No progress bar for saving the file. After 5 minutes without no signal of activity, OOo returns. Adding the URL for the file in question. Hwoarang
Tried it w OO2.0.1RC4: Saving as ODF still takes about 18 (EIGHTEEN) Minutes (W2k prof. en). Definitly too long and NOT acceptable! Seems to be a bug in the sxw/odf engine. No files are touched during saving (sometimes HDD LED lit 'cause OO is updating some temp files). Must be a problem in the engine itself. Could someone dig into the code and try to figure out what happens? Could it be the trueth, that such a great product if NOT capable to handle "real-world" documents? I don't think that OO should be limited to work only with files of < 10 pages!!!
confirmed on SRC680_m154 saving in my system least 15 minutes. maybe this issue depends on the same error as issue 54338 reassigned to os lowered prio to p3 set target OOo later (same reason as in issue 54338)
additional informations open and save (as sxw) least less then 3 minutes in a SO7pp1
Should be fixed in the next patch
This is also the case for OS X and applies to both Writer and Calc (haven't tested the others). One work around would be to have the save run in the back ground. Currently the slowness is a major impediment, espcially for those of use who do frequents saves. (Years of using Windows have left their mark and even on better platforms I still reflexively hit save every time I pause in writing.) Here is one medium-sized document that can take about two minutes to save even on a 1GHz G4: http://www.kursing.no/oo/Generell_Writer_Calc.odt
Target changed to 2.x
Can this be the trueth, that this is not a bug of high priority???? and assigned to a lter release (not for the first time) I can not agree! Pls. fix the bug immediately!!!!
Please correct the saving time in OOo 2.x it's just unacceptable, is even slower than in the 1.x series! Between this issue and its slow start time OOo is placing itself out of the game. Please Sun do something!
Just checked OO 2.0.4: Saving just costs 4 (FOUR) Minutes !!!! Is it the truth, that nobody can fix such a major bug. THIS SW IS NOT SUITABLE FOR PROFESSIONAL APPLICAIONS !!!!! Within months nothing has been done, just did some assignments and moved the milestones again and again to the future.
tjurk: can you update the download url ? the file is not available. thank you. Hwoarang
Zipped file now avail (again) for download: http://www.jurk-family.de/public/download/OO2Test/QuickStartOO2Test.zip Good luck
The problem seems to be the amount (more than 21000!) of index entries in this file and the handling of these entries at the UNO API of the writer.
This problem is not exclusive of Writer. I have a spreadsheet where I keep my personal account with something like 40 sheets and 4 graphs, and it takes 40 seconds everytime I (or the automatic backup) save the file. It's just *very* unproductive. I've just converted the file to .XLS and tried it in an old version of Excel (97) I have around, and it took only 1 second to save the same file (!!!). How can that be? Calc "thinks" for about 20 seconds before doing the actual file saving, and then it takes another 20 secs. to write the file to disk. I know all the benefits ODF is supposed to have, etc. But at this price (=time, remember?) I do not know much serious people who'd be willing to bet on it.
OO 2.2 released, still absolutely nothing happened. Still takes about 5 Minutes on a modern PC to save/load/import the file. Could someone pls. pls. pls. raise the priority? If there anybody responsible to fix that bug? Can this be the truth that most of the OO users are working with simple documents of only a few pages? What about the millions of students and their diploma? The bug has been provided approx. 2 years ago, unbelievable !!! I still need to work on this document using OO 1.1.5 !!!!
target 3.0
target 3.x
Unbelievable. Always moving pending work to the future. It seems that you are not interested in fixing the bug. Why do you develop new releases if the old bugs are not fixed?
It seems that you don't know anything about software development, so I apologize your rude tone. If an application of the size of OOo won't provide new features before all bugs have been fixed it would never get any new features and would be dead as a dodo in less than a year. So bug fixing must follow priorities derived from relevance, severity, effort, visibility and some other criteria. As we have very limited resources we have to follow these priorities very strict or we will risk not to do the things we think are important. You should see that a performance problem that happens only for a particular kind if document doesn't have a very high priority. Having a document with >21000 index entries is something that most users will never see in their life. There are a lot of more issues (and missing features!) that are much more important for much more users. os has pointed out what the performance problem is. What he didn't write here is that this would require a rework of the used API that will last for several weeks. This is something that we can't invest here at the moment.
FYI: Developer since > 20 Years for mission critical and industrial applications. Regarding the amount of index entries: What about diplomas? Students out of the focus of OO? Ok, let's come back on the technical stuff: How can i get rid of the index entries within the document to check what happens and to figure out what a possible wirk around could be?
Created attachment 53934 [details] Fixed document
->tjurk: The attached document should work for you now. The problem is the automatic creation of index entries with the concordance file. While updating the index all entries should be removed at first and then re-created. ->od: In case there's a concordance file used the update mechanism of alphabetic indexes removes all automatically generated index marks and creates new ones flagged as automatic. This 'automatic' attribute is not stored and is not part of the ODF spec. Reassigned to OD to get it added to ODF
-> os thanks for the fix. But i need to fix other documents too. Could you pls. provide a way to do this myself -> os which version did you use to create the new file. My 2.4.0 OO says that a newer version was used. -> os the Index-Markers in the document (formatted text, Index-Marker tooltip on Mouse-Over) you provided still exist. Any way to remove them?
Grabbing issue to fix the performance problem
Created attachment 59924 [details] proposed fix
Fixed in cws os108
Should have been cws os128 Reassigned for verification
Verified.
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues
Sorry this issue was wrongly closed. This issue will be reopened automatically. And will be set after that back to fixed/verified.
Set to state 'fixed'.
Set back to state 'verified/fixed'. Again. Sorry for the mass of mails.
Checked in DEV300m60.
Downloaded and installed the 3.2 release candidate (OOO320m8 Build:9472), and I assure you that the bug is still there.
mru->socrat3000: please file a new issue and attach your sample document; it looks, that it is a very different problem.