Issue 107775 - extremely slow upon opening a particular (damaged?) document
Summary: extremely slow upon opening a particular (damaged?) document
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: DEV300m67
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
Depends on:
Reported: 2009-12-18 17:35 UTC by richlv
Modified: 2017-05-20 11:15 UTC (History)
2 users (show)

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

xml excerpts of repeated information (3.49 KB, text/plain)
2010-01-04 15:53 UTC, richlv
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description richlv 2009-12-18 17:35:38 UTC
opening a specific document (contains lots of comments and recorded changes) becomes extremely unresponsive and it can be barely closed.
happens both with 3.1.1 and m67.
this is quite unfortunate, as i'm locked out of a document with a deadline 
already missed...

confidential document will be sent to mru
Comment 1 richlv 2009-12-18 17:46:35 UTC
document sent.

for the record, slowdown happens both with changes displayed and hidden (that 
can even be switched sometimes, after a long wait).
Comment 2 richlv 2009-12-18 18:18:48 UTC
seems to be caused by a large amount of hidden graphics (which might be just 
copies of the existing ones ?)

what's interesting, cutting out tect starting with the heading "Configuring e-
mail parameters" leaves lots of these duplicate images suddenly visible in the 
document. couldn't test much more as it's still awfully slow.
Comment 3 richlv 2009-12-18 18:41:25 UTC
sorry for spamming the issue, but i'm discovering new facts :)
after cutting out half of the doc, image count went down and the other half can 
be edited just fine.

so there are two problems.

1. messed the document up, creating these image entries (i verified the 
original, it does not have such any invisible images);

2. it still would be nice if it could handle the mess it created and not slow 
down to become unusable... i tried increasing image cache considerably, but 
that doesn't seem to help.
Comment 4 richlv 2009-12-21 09:01:12 UTC
i managed to "fix" the document by unzipping and editing xml.
it seemed to me that one image was listed in edit history many, many times.
Comment 5 Rainer Bielefeld 2009-12-25 18:27:03 UTC
Closed due to comments from richlv Mon Dec 21 09:01:12
Comment 6 richlv 2010-01-04 14:19:45 UTC
i'd like to ask for reopening. i just had another document get corrupted like 
that (with m68). so there are two issues here :

1. inserting lots of useless, redundant change information...

2. ...which it can't handle itself later.

it would be most important to find and fix the cause of the first, and, if 
possible, make it more efficient for the second.
Comment 7 richlv 2010-01-04 14:29:39 UTC
this just happened _again_. i would consider this a blocker as it can result in 
dataloss. i'm reverting to 3.1.1 myself, hopefully this problem won't be in 
that version.
Comment 8 richlv 2010-01-04 15:28:09 UTC
for the record, i decided to try 320m8, just in case. it broke my document just 
like m67/68 did.
downgraded back to 3.1.1, so far editing seems to be fine.
so this issue will affect 3.2 as well, and i believe it is quite serious.

for me, it seems to be provoked by deleting some things with change recording 
enabled. deleting some text (either with del/backspace, or starting to type 
with text selected) results in slower and slower operations, and in the xml 
file i can find lots and lots of redundant image deletion entries (even though 
i haven't deleted any images).

in the first case it was single image repeated, in the second case there were 
two images alternating in the entries.
Comment 9 eric.savary 2010-01-04 15:39:58 UTC
@MRU: did you get richlv's document? Canyou please have a look?
Comment 10 richlv 2010-01-04 15:53:36 UTC
Created attachment 66974 [details]
xml excerpts of repeated information
Comment 11 richlv 2010-01-04 15:54:56 UTC
i just attached an excerpt from content.xml which shows few starting instances 
of repeated entries.
repeatings are always twice in this file. nuking them to leave only one entry 
of each fixes the document.

so far this has happened in two different documents as well.
Comment 12 michael.ruess 2010-01-04 16:18:41 UTC
MRU->OD: problem is reproducible when you open it and try to scroll through it.
Somewhere when reaching page 12 you will notice that Writer will be stuck for
about a minute.
Because it is not (like) a crash Prio is P3.
Comment 13 Marcus 2017-05-20 11:15:39 UTC
Reset assigne to the default "".