Performance problems with a large document

English
, , , ,
#1

Hello.
I have a few performance problems with a specific document – it’s a large book whose stats are:

Pages: 699,
Tables: 1,
Images: 8,
OLE objects: 0,
Paragraphs: 4851,
Words: 229038,
Characters: 1445818,
Characters excluding spaces: 0 (?),
Lines: 22678 - file size: 10MB.

Images are small and bi-level – most of them have been added in the past days and the problems I’m going to describe were already present before, so they shouldn’t be involved. Problems:

  • Most of the time when I open the document and do nothing the CPU is already at 99%.
  • Most of the time LibreOffice is very slow in typing, in a way that is really affecting usability. Now fortunately my book is almost finished and I just have to do some small fixes, so I can survive; but when I need to rewrite a whole paragraph I need to open a new, empty document, write the text into it and then copy/paste.
  • Note that the problems sometimes disappear by themselves for a short time: let’s say that 20/25% of time the CPU goes down and typing is acceptable – note that these are two independent behaviours, that is sometimes I can type with no problems but the CPU is still at 99%.
  • A very strange behaviour happens with accented keys (I have an Italian keyboard and the text is in Italian): they always act very fast and while typing a word with mixed characters the accented ones go “out of order”; for instance, if I type “perché” I get “éperch” - I can see the “é” being displayed immediately, while “perch” gets later.

From LibreOffice about:

Version: 6.3.1.2,
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273,
CPU threads: 8; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; ,
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US,
Calc: threaded

Furthermore: 16GB RAM, my SSD has got 200GB free, its native speed is 2+GB/s, but the document I’m working with is on a VeraCrypt strongly encrypted partition whose performance is 80+MB/s.

I don’t have direct access to a native (i.e. not virtualised) Linux or Windows box with a performance comparable to my laptop, but I could ask some friend to help if such a test can provide useful information for diagnosis.

Thanks.

Points added to answer questions

I’ve tried copying the file to an APFS partition - still encrypted, but APFS encryption is less strong and much faster than Veracrypt, I measured performance at 1000+MB/s writing and 2000MB/s reading. Still same behaviour.

I use native .odt format.

A point that forgot to mention in my original post is that I use lots of references to user defined fields. They could be in the thousands (lets’ say 3.000 as a rough estimate).

#2

I’d say 10 MB is rather small and perfectly manageable. You have ample memory. Is your document saved native (.odt format)? What happens if you work on a non-encrypted partition?

To answer these questions, edit your question. Answers are reserved for solutions.

#3

Answered above.

#4

What are those “user-defined” fields? Bookmarks? Cross-references? Document properties? Some other “heavier” type like data retrieved from a database; data read from form control widgets?

#5

I think about 50 cross-references to chapters (this should be normal), the others are “variables/user fields”: they are plain strings (the document is a novel and all the names of the characters are defined as user fields).

#6

These are simple insertions (no math or formula). I think they should not be the cause of the problem.

Try to isolate the problem by bisecting: make 2 copies of your document. Put aside the original. In the first copy, erase the second half, making sure you keep the definitions of the user fields. In the second copy, erase the first half also keeping the definitions. Close both and reopen. Which one has the issue?

If only one exhibits the problem, iterate on it. You should discover the problematic object. With 699 pages, there are a maximum of 10 iterations.

If none, add half the second to the first. Close it, reopen. Progressively add more bits to the first until the problem shows up. This would mean this is a size issue, but I doubt it.

1 Like
#7

Ok, I’ll do.

#8

It is probably normal behaviour with a large document with many images and footnotes where it can take LO 30 minutes or more to layout a document. I tested a document with 2 million words, 8,000+ pages and 800+ footnotes which was very slow.

When you open a large document, LO is unresponsive for several tens of seconds (or several minutes) and LO then becomes responsive. However, while you can now edit, LO is working hard in the background laying out the document. If you scroll during this time - you shouldn’t - you can see white gaps.

Look at the page count at bottom left where you will see the page count will vary wildly and it may take many minutes before it stabilises at the correct number. Or, start TaskManager and watch the LO CPU usage - LO is laying out until the CPU usage falls to a low value.

Temporarily convert all footnotes (at the bottom of the page) to endnotes (at the end of the document) while you are editing as this will speed up layout. Convert them back as the last thing you do before creating the ToC and allow a long time for layout. Alternatively, edit in Web View as each “page” is 10 ? metres long so there are fewer page transitions to be laid out.

Make sure image anchors are close to their images.

It will be necessary to see the actual document to offer more advice.

1 Like
#9

Thanks! I have high confidence this will fix my issue. How do I do this?
Do I need to select all footnotes? I have 320 pages worth.
Ah it’s in Tools → Footer/Endnotes…

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.