Bug 39178 - Writer EDITING, FILESAVE: Working of "record/track changes" is extremely slow (Press enter takes one minute)
Summary: Writer EDITING, FILESAVE: Working of "record/track changes" is extremely slow...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2011-07-12 12:28 UTC by dav00qqq
Modified: 2023-12-28 03:11 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
large ODT files with revision marks (2.08 MB, application/zip)
2012-10-22 12:45 UTC, stfhell
Details
Perf flamegraph (1.72 MB, image/svg+xml)
2019-04-19 07:56 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dav00qqq 2011-07-12 12:28:24 UTC
I'm working on a 307 page document in LO Writer 3.4 (Ubuntu 11.04), saved to .odt which before that was a .rtf doc, edited in ms word. I've been tracking/recording changes for quite some time, and there are extensive changes through the first 65 pages.

Save time= over 18sec.
The same document with all changes accepted, save time= 6.5sec.

Obviously each save of my working document is writing all the changes to part of the file.  So is it saving them ALL each time?  Wouldn't it work saving the newest changes (ie appending them to that part of the file)?  Ms Word didn't take so long saving.
Comment 1 Björn Michaelsen 2011-12-23 12:26:33 UTC Comment hidden (obsolete)
Comment 2 sasha.libreoffice 2012-01-27 10:07:47 UTC
18sec is not so much. And from other side users can rest some while document saves.
But developers work on optimization of LibreOffice. In next version saving will much faster.
in LibO 3.6.0 Master on Fedora 64 bit document more than 300 pages changes saves 6 sec.
Comment 3 Florian Reisinger 2012-08-14 14:01:54 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:02:56 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:07:31 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:09:37 UTC Comment hidden (obsolete)
Comment 7 stfhell 2012-10-19 16:48:29 UTC
I am reopening this bug because the problem is there, actually. I'm aware that there is no easy solution for it and that one has to be prepared to go on living with the issue for still a while, but it _is_ a problem for some usage scenarios.

Problem:
If you edit a large document in Writer (200+ pages) and use the "record/track changes" function (redlining) a lot to have revisions recorded, Writer will become more and more inefficient to work with due to the growing number of revisions recorded.

(1) Disabling "show changes" is explicitly discouraged by LO (the dialogue that says: Hiding changes makes everything slow, would you not rather prefer to show them again?) because hiding changes makes editing a pain in larger documents.

(2) Saving a file takes _much_ longer (rough guess: 3-10 times) with many changes recorded - and, I'm sorry, you cannot discuss that away with a Comment #2 like, "Hey, 18 secs to save is not that long, and you can go and have a cup of coffee while LO is saving". Saving is not done in the background, and you have to wait for it to finish. And this does not only concern regular file saves via Ctrl-S, but also the auto-saves, of course. (And you need auto-save!)

(3) For some reason, normal text editing isn't slowed down that much, but inserting a new paragraph is excessively so. Depending on the number of recorded changes, it can take 5-10 seconds to have it inserted. Interestingly, it's much faster to do the same thing by using the clipboard: Copy an empty paragraph and insert it where you want a new paragraph instead of hitting Return.

Of course, all this concerns only people who edit large texts (200+ pages) and actually use "record changes" heavily (say, some hundreds of changes in the doc). But if this scenario covers your usage of LO, you _do_ have a problem. You have to split the document in 50-page units or disable "record changes" as much as possible.

I think, with modern hardware in mind, editing a 400-page document with 10 recorded changes per page should be possible without a word processor becoming virtually unusable. But it's probably more of an enhancement than a bug...
Comment 8 sasha.libreoffice 2012-10-20 08:37:20 UTC
Thanks for additional testing
Please, tell exact version of LO which works slow (3.5 or 3.6 or 3.7?).

If possible, attach document that demonstrates that LO is slow with much red lines. It is important, because developers have no time for creating this document and other users use red lines very rare for interesting in this. Such document may very help in improving LO.
Thanks in advance
Comment 9 stfhell 2012-10-22 12:45:28 UTC
Created attachment 68913 [details]
large ODT files with revision marks

I cannot post orginal documents (since they are confidential and I try to avoid overusing track changes), but here is same sample text with a macro that I used to make random edits (insertions, deletions, replacements of random bits of text). OTDs created and saved with LO 3.6.2.2.

a) 39178_swift_is_slow_1_original.odt :
Original document without any redlines, 240 pp, 314 KB, saves in ca. 4 secs on my system.

b) 39178_swift_is_slow_2_revmarks_1.odt :
Same document with ca. 10 redlined edits per page, 423 KM, saves in 20 seconds.

c) 39178_swift_is_slow_2_revmarks_2_without_revision_marks.odt :
Same text as (b), but without redlines (i.e.: deletions rejected and insertions accepted), 322 KB, saves in ca. 4-5 seconds.

d) 39178_swift_is_slow_2_revmarks_5_compare_with_original.odt :
Document comparison between original version (a) and version (b) with all changes rejected.

e) 39178_swift_is_slow_3_revmarks_1.odt :
Just doubles the text amount of document (b): 480 pp, 798 KB, saves in 62 seconds. (The same document but without revision marks - like in version (c) - is 598 KB and saves in 4 seconds; not included in the package.)
Comment 10 stfhell 2012-10-22 13:57:41 UTC
Some comments regarding attachment 68913 [details] and Comment #7:

Usability issues with revision tracking have been more or less the same from StarOffice through OpenOffice to LibreOffice, because there has been only basic maintenance of the redline feature of Writer in all these years, as it seems to me. Therefore, it doesn't really matter which version of LO you are looking at.

Re (1):
Open 39178_swift_is_slow_2_revmarks_1.odt (240 pp) or 39178_swift_is_slow_3_revmarks_1.odt (480 pp). Disable "show changes" and edit the document for a while. Insertions works fairly smooth, deletions take long (8 seconds) to display.
Working with hidden changes is something very useful: It gives you the correct final page layout and document size; it allows you to find and replace text excluding already deleted text; and with a lot of revision marking it can be difficult to read the text with all the deletions in between.

Re (2):
Saving the bare un-redlined files is usually a matter of about 4-5 seconds. With about 10 edits per page, it is 20 seconds for the 240pp document and over 60 seconds for the 480pp document. While this is probably merely unpleasant with normal saves, keep in mind that auto-saves behave identically, of course. Saving the redline info takes exceptionally long if you consider how litte data size is involved.

Re (3):
Open one of the files with redlines and insert some paragraphs anywhere. It takes about 7 seconds on my system with the 240pp document for 1 paragraph.


Another constant source of trouble is the chronic unreliability of the "track changes" function. Not all changes of the document are redline-able, so some changes are not tracked at all (e.g. graphics or draw elements). But even the tracked ones do not behave as they should. Take for example 39178_swift_is_slow_2_revmarks_1.odt and reject all changes made; then compare with the original document 39178_swift_is_slow_1_original.odt. Of course, there should be no differences - but there are (I already filed that as a bug). All the little shortcomings add further to the inefficiency of working with "record changes", because even if you know about them, there is always some manual cleanup to do after accepting all changes.
Comment 11 sasha.libreoffice 2012-10-22 14:24:08 UTC
Reproducible problem with slow inserting of new line (60 sec) and long saving (90 sec) in 3.6.3 on Windows XP 32 bit, CPU is Celeron 1.8 GHz.
(used file 39178_swift_is_slow_3_revmarks_1.odt with 480 pages)
Inserting new line in OO 3.2.1 is also very slow, therefore it is not a regression, but inherited problem
Changing importance to "normal"
Comment 12 sasha.libreoffice 2012-10-22 14:31:35 UTC
@ Michael
Greetings
What do You think about this bug?
Comment 13 Michael Stahl (allotropia) 2012-10-22 15:02:44 UTC
it's well known among Writer developers that the
change tracking implementation in Writer has serious
reliability, feature and performance deficiencies.

a lot of crashes were fixed over the years, but the
fundamental design problems that make it slow
will take a lot of time to fix.
Comment 14 QA Administrators 2015-01-05 17:51:19 UTC Comment hidden (obsolete)
Comment 15 Michael Stahl (allotropia) 2015-01-05 22:29:46 UTC
the relevant comment is still in the code

"//JP 06.01.98: MUSS noch optimiert werden!!!"
Comment 16 Björn Michaelsen 2015-02-27 12:32:45 UTC
as per comment 10: adjust version
Comment 17 tommy27 2016-04-16 07:26:45 UTC Comment hidden (obsolete)
Comment 18 Michael Stahl (allotropia) 2016-04-18 09:25:44 UTC
//JP 06.01.98: MUSS noch optimiert werden!!!
Comment 19 QA Administrators 2018-04-19 02:34:40 UTC Comment hidden (obsolete)
Comment 20 Luke Kendall 2018-11-24 03:35:50 UTC
This was very much the case with LO up until around version 6.1.2.1 (or perhaps the release version before that).  Performing the steps as described required a wait of a minute or more.

Strangely, a workaround was to *paste* a paragraph break rather than just hitting Enter.

However, as of a recent version of Writer, this problem has been fixed.
Comment 21 Adam Kovacs 2019-03-19 15:39:58 UTC
(In reply to Michael Stahl (CIB) from comment #15)
> the relevant comment is still in the code
> 
> "//JP 06.01.98: MUSS noch optimiert werden!!!"

since then... this was the latest version with that comment =)
https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/DocumentContentOperationsManager.cxx?r=c253dde8#3753
Comment 22 Buovjaga 2019-04-19 07:56:11 UTC
Created attachment 150874 [details]
Perf flamegraph

Traced the saving of 39178_swift_is_slow_3_revmarks_1.odt as it was mentioned to be the slowest.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 18 April 2019
Comment 23 QA Administrators 2021-12-27 04:06:28 UTC Comment hidden (obsolete, spam)
Comment 24 QA Administrators 2023-12-28 03:11:06 UTC
Dear dav00qqq,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug