Writer high cpu usage 7.3.7.2

English
,
#1

I have started getting high CPU usage for no apparent reason anywhere from 2 to 20 minutes into a session. At first the only way to get rid of it seemed to be to shut LO down and restart it. Oddly, I discovered that in my case, making the formatting marks visible stopped the high cpu usage. The document has text, tables, graphs and frames.

I am not sure:
A) if this will help LO track-down the issue, or
B) if LO cares as apparently there was one post that removing LO was the solution. (LO competitors might appreciate this apparent lack of concern by LO)

There have been numerous high-cpu usage issues, I do not know if they are related, but LO might consider aggregating and categorizing them so users could easily find a possible workaround.

Version: 7.3.7.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3
Calc: CL

1 Like
#2

When you enter this high-CPU usage, have you any network or USB devices which went suddenly missing?

#3

@ajlittoz no, this computer has two usb wired devices (keyboard and mouse), wired network connection, no wifi, no bluetooth.

#4

And have you traffic on the wired network, like attempt to access a printer or link to a “security server” for things like certificate, … In case the “servers” don’t respond, you must wait for time-out (but it should be shorter than 20 minutes).
Another possibility could be a nearly-saturated disk where the OS launches disk reclaim for space. I sometimes incur such slow down when the OS schedules RAID resync (in my case: 3 hours without any activity, more if I work simultaneously) but this is related to my configuration for high reliability.

#5

@ajlittoz no, this just starts while editing the documents.

Network: 1Gb local Ethernet.
File server on network used for manual backups (that is where the raid is)
Disk is SSD NVME with 3TB free.
Printer on the network in deep sleep mode until something is sent to it.

LO writer is the only application running, launched right after booting.

In short, there is nothing else going on when this happens.

Given that the viewing the formatting marks seems to stop the high-cpu usage, and your other comments and warnings about using frames anchored to page… is it possible that the high cpu-usage could be due to some sort of formatting calculation loop?

And before you ask:
Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz
Memory: 62.4 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1650 with Max-Q Design/PCIe/SSE2

#6

I don’t think formatting marks have any impact on the behaviour.
Formatting computation is possible but details about your document are necessary. Number of pages won’t be a problem on your machine. Hundreds of pages can be handles like a charm. Slowing factors include number of tables (and their structure if you nest tables in cells or merge cells in non-trivial ways) and number of frames (properties of frames have more impact than tables).
According to my experience with sophisticated technical documents, I don’t see performance loss in a 400-page doc with ~150 small simple tables and ~100 frames.
Direct formatting may also slow down text reflow but not to the point to lock CPU for 20 minutes.
If you don’t mind, attach your document to a private mail. If it is bigger than 5 MB (AskLO limit), I’ll give you a real @email @ddress through private message.

#7

The document is confidential. But it has Sections, 3 frames with graphs and captions, and 3 tables. I have tried several, on two different machines (same version of linux and LO), this is the smallest and it has the same problem as the others.

Why would making the formatting marks visible stop the high cpu-usage?
Note: soffice.bin is the high cpu-usage culprit.

#8

3 frames (and probably as much for the images) and 3 tables make your document a small one. Then the cause should be looked for in your formatting routine. Do you use styling or mixed styling + direct formatting?
I assumed your document is confidential. This is why I offered to examine it through a private channel. It’s up to you.

#9

@ajlittoz , Why do you presume it is the document at fault, and in particular styles?

In the documents in which this intermittent problem is occurring, I have not used any custom styles. The only styles are the default ones.

Is not claiming that an intermittent problem did not occur on your system tantamount to denial?

Again, I suggest that LO aggregate and order all the “high cpu-usage” posts as it may help the developers identify the root cause. Perhaps one of the developers would know right away what high cpu-usage code might be negated or skipped by using view formatting marks. Is it then possible that looking at the organized postings, a knowledgeable developer might actually identify the cause?

Regards,

#10

The principle of debugging is to check all obvious causes in order to keep only a few leads and explore them each in its turn.
I already designed documents which departed from the intended Writer usage in such a way that the app froze. In every case I was off-spec. Since Write has decent performance for well-behaved documents, I first incriminate my document and it is quite rare that the behaviour betrays an internal bug (I know, no application is bug-free). The point here is that “correct” usage is not explicitly delimited in the available documentation.
If you practice direct formatting intensively, you more prone to mishaps than with full styling. Don’t forget that paragraph styles are only the visible side of the iceberg. There are many more style categories and they are too often neglected.
There is no intended offence from my part in hinting that the document is the primary factor in the problem. This is only experience.

#11

Hi, I have the same problem

  1. Installed a fresh Ubuntu 23.10.1 on a 4 core Intel PC. (16GB RAM, no SSD)
    1.b: Installed OpenRazer for the mouse: https://openrazer.github.io/ with Polychromatic
  2. Used GFuse ( github. com/astrada/google-drive-ocamlfuse/ to mount Google Drive)
  3. Opened a .odt file. It opening fast.
  4. Try to scroll the document, one core of the CPU is at 100% (25% overall).
  5. After some time (e.g. 4 sec.) it scrolls one DIN A4 page down.
  6. Up-Scrolling the same.
  7. Used version: LibreOffice 7.6.: https://gerrit.libreoffice.org/gitweb?p=core.git;a=log;h=4fe86607b5ac922e55f140471fda9b60bdaa980d
  8. the GNOME setting for the mouse scroll direction: “Traditional” vs. “nature” (german translation, english UI might have different words). Also change the CPU usage. traditional more around 25% and nature more towards 45%.

→ with the first opening of a document with Libreoffice it seams fine. The second document has the same problem, now a .odt file.

#12

Same kind of issue here, but with Draw:

Version: 7.3.7.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.7
Calc: threaded

  • Linux Mint 21.3 Cinnamon X11
  • 32 Go RAM / SDD 400GB free / 13th Gen Intel© Core™ i7-1365U Ă— 10 (notice : not 12 cores)
  • no USB storage device plugged

Seems to appear on save time since it happens every 10 minutes or so (but not all the time) OR sometimes when I save the documents.

  • The GUI freezes for several dozens of seconds.
  • Documents : 1 to 4 pages and as many images used as text zones, without any custom style set.

I’ve set my CPU governor to perf instead of powersave which seems to reduce the freeze duration (form about a minute to 20/30 seconds) but it makes my fans make much noise (activity confirmed by the system monitor).

I can send you some of those documents but the uploader says they are more than 4 MB (tried several times until 1,5 MB ODG file was rejected) which isn’t convenient.

Regards.

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