Apache OpenOffice (AOO) Bugzilla – Issue 75680
Editing Writer document using change record is slow
Last modified: 2013-08-07 14:44:35 UTC
Working on a complex but short (12 pages) Writer document using change tracking is too slow to work effective using this feature. An examle scenario, the last before writing this bus: 1)Turn on View Changes (optional - even slower) 2) Exchange the string '../styles.xml#some-id' with 'urn:uuid:224ab023-77b8-4396-a75a-8cecd85b81e3' 3) Add a Caridge-Return behind that line (slower with change tracking) 4) Save the document
Created attachment 43889 [details] Complex but short Writer document having problems with Change-Tracking
Created attachment 43903 [details] new bugdoc
Open new bugdoc, save file, have a look at the resulting content.xml. There are not 2 alphabatic-index-marks in the deletion redline. Reproducible also with m124! Looks like there's a bug in SwTxtNode::Copy(): There is an index mark at position 13-32 and at position 15-21 (which is the region of the deletion redline). Saving the document, SwRedline::Hide() is called. The region 15-21 is moved to the redline section of the document. After this there are two index marks in the redline section, because it is assumed that the attribute from 15-21 has to be copied as well. This seems to be the bug. (Note: There's a comment in the source code: "Never copy refmarks". Perhaps this should also hold for toxmarks). After this SwRedline::Show() is called again and we end up having an additional index mark at position 15-21 in the hintsarray.
move to 3.x accroding http://wiki.services.openoffice.org/wiki/Target_3x
I had the same problem in my document, and in some others on which the same issue was seen. For me, 2 hours to have the hand on the document after a carriage return, on a 3GHz computer. I found out that in content.xml, some lines get repeated without any apparent reason. Example: </draw:line><draw:line text:anchor-type="paragraph" draw:z-index="223038" draw:style-name="gr1" draw:text-style-name="P60" svg:x1="29826.16cm" svg:y1="-29826.156cm" svg:x2="29833.392cm" svg:y2="-29826.156cm"> repeated over 50,000 times after a paragraph. This happened after having enabled change recording and having made many changes (around 500 if I look at the xml file). Since this part was modified, it appeared 2 times: in the text:tracked-changes section, and in the office:body section. Having manually deleted these draw:line in content.xml and re-zipped the document, everything came back as fast as before. On another document, a different line: </draw:frame><draw:frame draw:style-name="fr1" draw:name="images33291" text:anchor-type="char" svg:width="6.001cm" svg:height="1.39cm" draw:z-index="0"><draw:image xlink:href="Pictures/10000000000000F50000003993485078.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> Around 30,000 times. In this case there is a picture, having reduced to 1 occurrence this line solved the issue. This is a major bug I experienced in all OpenOffice-based suites (Windows/Linux), since we migrated from 3.0 to 3.2 version. Same behaviour with DEV300m106 Many documents here have been seen with this bug, all after this version migration. The users that stayed on 3.0 release do not have this issue.
It seems to me that 2 completely different issues got mixed in this bug report. (1) The redlines implementation in Writer is not particularly robust or efficient. Any document with a considerable number of recorded changes will slow down editing. Editing a document with "View changes" _disabled_ is a pain. With "View changes" _enabled_, deletions and insertions of new paragraphs take several seconds, even over a minute, depending on the number of redlines and the CPU. Saving a document with a lot of tracked changes can take up to 10 to 20 times as long as without tracked changes. I suppose, that was the issue addressed by the reporter. (2) Writer sometimes replicates elements infinitely in a redline deletion and in a text paragraph. This seems the issue which is addressed in Comment 5 (and probably also Comment 3, but may be unrelated). I opened Bug 121452 for this issue (with frames).