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.

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...

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

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.)

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.

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"

@ Michael
Greetings
What do You think about this bug?

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.

the relevant comment is still in the code

"//JP 06.01.98: MUSS noch optimiert werden!!!"

as per comment 10: adjust version

//JP 06.01.98: MUSS noch optimiert werden!!!

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.

(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

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

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