The multi-threading option only appears under the Calc options. Does anyone know if there is a way to enable it for Writer? (using LO 7.5.2 Win).
I have been watching a document try to write a cache (1.3 GB and climbing) for hours, while only 1/8 cores is being used. OpenCL is enabled.
I suppose that the document is full with unoptimized images.
My tips:
-
Optimize images before you embed them into a textual document. Then the file size will be drastically decreased:that requests less processor time and memory.
-
Switch off the appearing of the images during the edit of the document. Then only a placeholder will be appeared: that will be faster.
Thanks, but there are no images in the document. LO was just installed fresh on the system to test it, so I doubt it is a corrupted user profile. Troubleshooting in a different thread. Just inquiring about multi-threading here.
Additionally, it climbed to 5.4 GB over the following 12+ hours. The CPU usage climbed up to 17% at one point, indicating that 2 cores of 8 were in use, so I guess the question is answered, and OpenCL does allow some multi-threading in Writer.
(LO is attempting to move footnotes to the end of a section. Otherwise, it works excellent.)
- OpenCL is really only applicable to Calc, and is not used elsewhere in LibreOffice.
- “Multithreading” is used everywhere - LibreOffice simply can’t run in a single thread. But that doesn’t mean that the work in threads can always go in parallel - which is what you observe.
- In Calc, there is a special calculation mode using parallel threads, which can be configured using the settings you refer to. That configuration does not alter reading from file / writing to file / painting / caching, etc. So that configuration is also unrelated to any other module.
- But there is a difference related to XLSX files, absent in other file types: XLSX uses different internal XML streams for different sheets, and LibreOffice can parallelize the work reading/writing them. This is unlike e.g. ODS, where all the sheets are stored in the same XML stream, so the work can’t be parallelized, unfortunately. This makes XLSX performance better than of the native ODS, when there are several heavy sheets. In other files, like DOCX/ODT, there’s no such property of storing heavy data in different streams, so no difference.
Work with images is similar in all cases of modern file types; if you have specific reproducer with poor performance, filing a perf
bug with such a reproducer could help improve it.
Thanks mikekaganski! That’s an excellent answer to the question. I hunted around for an explanation for this, but couldn’t find anything clear.
If I can figure out what the actual issue is, and assuming it is not an error in my file, I’ll request a bug fix.