Issue 75680 - Editing Writer document using change record is slow
Summary: Editing Writer document using change record is slow
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-03-23 14:52 UTC by svante.schubert
Modified: 2013-08-07 14:44 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Complex but short Writer document having problems with Change-Tracking (74.25 KB, application/vnd.oasis.opendocument.text)
2007-03-23 14:57 UTC, svante.schubert
no flags Details
new bugdoc (11.55 KB, application/vnd.oasis.opendocument.text)
2007-03-24 11:45 UTC, frank.meies
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description svante.schubert 2007-03-23 14:52:04 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
3) Add a Caridge-Return behind that line (slower with change tracking)
4) Save the document
Comment 1 svante.schubert 2007-03-23 14:57:47 UTC
Created attachment 43889 [details]
Complex but short Writer document having problems with Change-Tracking
Comment 2 frank.meies 2007-03-24 11:45:36 UTC
Created attachment 43903 [details]
new bugdoc
Comment 3 frank.meies 2007-03-24 11:58:51 UTC
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
Comment 4 Martin Hollmichel 2007-09-10 13:52:48 UTC
move to 3.x accroding
Comment 5 thierry.merle 2011-05-22 15:08:24 UTC
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.
       </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.
Comment 6 stfhell 2012-12-08 23:46:42 UTC
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).