A file with a large number of comments becomes unstable, uneditable. What to do?

[JackTheLabRat]

LibreOffice Writer 5 misbehaved badly under Ubuntu 16.04. With file Ur-Text.7.docx up, keyboard and page control
were extremely sluggish. A slight turn of the mouse scroll wheel began a slow, line-by-line march downward. The march never ended. The machine slowly locked up. I tried to bring up the System Monitor with no success. Within 90 seconds, the machine was completely unresponsive. I had to hit the reset switch.

I installed LibreOffice 6. Writer 6 was similarly unstable and completely unuseable. Something in Ur-Text.7.docx
makes LibreOffice Writer misbehave.

I had an installation LibreOffice 5 installed under Windows 10. Editing of Ur-Text.7.docx under Writer 5 performed no better under Windows that it had under Ubuntu. I converted the file to Ur-Text.7.odt and tried again. Editing was still unstable.

The common element among these tests may be obvious. File Ur-Text.7.docx itself is nothing special. It consists of 135 pages of 10-point text divided into about 20 sections, each of which corresponds to a single outline number. It also contains about 600 comments, all but perhaps ten of them short 11-character references to another document. If I remove the comments, Writer edits the file without complaint. Evidently, the performance of a document’s in-memory representation degenerates if the document contains several comments per page.

Recent severe problems with Windows 10 update 1803 made me realize how badly I need to keep my Linux program base in place for the too-frequent times when Microsoft falls off the wagon. I will be happy to work with someone who’s interested in this problem and has some traction with the LibreOffice group.

[mikekaganski]

What you describe is a bug (unacceptable performance and hang, equivalent to crash). Thus, it is off-topic here, and should go to bug tracker. Please prepare a test document showing the described behaviour (it should be straightforward) and attach to the issue; wrt a fix - I suppose it’s not too easy in this case, so a patience might be required

[mikekaganski]

For a sample document, you could use this one that I have just created; and yes, opening it with LO is slow; navigation is also slow, regardless one enables or disables view of comments (View→Comments), even after pagination finishes; but right-clicking any of comments and selecting Delete All Comments makes it behave fine.

[JackTheLabRat]

Mike Kaganski. . .Thank you for the suggestion. Living without the comments is not an option. I’ll move my gripe to the bug tracker in a few days after I shroud the text - It’s copyrighted.

[gabix]

Try Apache OpenOffice. In my experience, it is more stable as compared to LibreOffice.

[Lupp]

Do you expect AOO to better handle a .docx with many comments?
Typically .docx are from alien source and comments are mainly used trying to organize “teamwork” editing the document under changing software / versions then. That won’t long endure, I’m afraid, whether with LibO nor with AOO. In forum.openoffice.org/en there are requests again and again to help with repairing files corrupted due to the mentioned pratice.

[gabix]

As far as I understand, the topic starter tried processing both an original DOCX file and a converted ODT file. Thus, I expect AOO to better perform with a large file (once converted to ODT). And, of course, I don’t expect miracles, so I say: try.

[Lupp]

[Use the native ODF format (.odt for text documents).]

Editing with respect to the comment below by @mikekaganski.
You are right, and I had already edited my answer to much more detail when this silly Windows got crazy. The correct answer was lost, and I had to restart the great Win 10. (To use ODF is always a good advice, I thought.)

Now rewriting from memory:
I took the time to create a simple example with >200 pages and about 1000 comments. Due to the flat structure and no inserted extra TextContent the packed file was only about 40 KiB.

V6.1.0.1RC needed a few (about 4) seconds to open the ‘Goto Page’ dialog, and then some more (up to 10, not exactly reproducible) to complete the execution. Roughly reproducible. Ordinary insertion by typing text also stumbled unacceptably. The behaviour clearly reminded me of WinWord 25 years ago.

V5.4.4 Portable basically also showed the issue, but was faster by 30% ~ 50%.

V3.3 (Legacy!) sometimes already refused action and even completely closed when I tried to enter the new page number. In another case it accepted the number and the complete failure followed after that. V3.3 later offered recovery but failed (not clearly reproducible again).

If anybody wants my test file to add it to a bug report: demoSlowNavigation.odt

Editing again:
Concerning the “What to do?”
Less comments? (Possible?) Having cleared out all the comments my demo was faster than a lightning.
Ever tried to user a Masterdoc?

[mikekaganski]

Unfortunately this is not a conversion problem; rather, it’s a problem of inefficient code handling floating objects (which are used to implement comments). See this sample created the same way as the .docx from my comments to question above, but in LO as ODF from start.