@laurens : we would really need a small sample document to be able to reproduce the problem.

From your profiling, I see calls to IsContentFrame() 

1) are you using lots of frames in your document ?

2) what does each frame contain (content / formatting / legends / spacing / padding) ?

Unfortunately I don't know what frames are (I can see the menu item - never used it in 10years of LO/OO/StarOffice use).

I have about 20 2x1 tables with PNGs inserted and associated captions and perhaps 30 "normal" text tables (5x5 or so). PNGs are mostly 1600x1000 

I deleted the picture in the headers, but that had no effect. 

Is there somewhere I can get document stats that might be useful for debug (e.g. no of frames, no of objects, etc)?

Ah - I see that Frames are autocreated when I add captions to graphics - in that case I have about 30 frames...

The CPU usage might be due to Writer attempting to refresh the screen display layout constantly (I seem to remember that this happened a lot with inserted images) and perhaps this is triggered more or compounded by the presence of the frames.

Ideally, we would still need a minimalist sample document where the problem could be seen.

(In reply to laurens from comment #5)
> I've tried to make a smaller redacted document, but of course this is not
> showing the problematic behaviour. As this is a work document, it is
> unfortunately out of the question to share :/
> 
> A lot of the images are scaled - I wonder if that might be causing a
> problem? 
> 
> The problem is that this a showstopper for me to use LO at the moment due to
> this issue as I need battery life...

LibreOffice 6.1 has some image handling improvements. It might fix the issue.

(In reply to laurens from comment #10)
> I deleted my profile and ran both 6.0.5 and 6.1.0 on macOS and the system
> behaved well for a while (no excessive CPU use).
> I did try redoing one of the tables (and frame) on the first page at the
> same time. 
> 
> But it seems that the problem has returned last week, it's possible that a
> colleague has edited in Word 2016 (but not sure - and he cannot remember)

So it worked well for a while and suddenly the problem arose again?
Do you remember doing any action to trigger it ?

No, I cannot think of anything that may cause it. Currently running  6.1.0.2 on macOS 12.3.6

I have an old StarOffice document with a lot of frames that does the same thing (100% CPU after a while, back to 0% CPU if I scroll to all the way through the document to the first page). That document will never have been converted to MS Word, so I don't think that docx contamination is a root cause.

Unfortunately the docs that show this behaviour are from work, thus I cannot share. 

I have a sample document that may be able to share - I cannot confirm that it has the same problem exactly - but it uses up to 50% CPU whilst typing according to Activity Monitor and everything feels slightly "sluggish". When I move a picture to a page below then the CPU usage drops to 20-30% whilst typing.

I also have the Activity Monitor sample of the threads executing when there is high CPU usage whilst typing.

Can that be of use?

The same bug affects me too on Xubuntu 16.04 with LibreOffice 6.0.6.2, except scrolling through documents doesn't help. When I open a document, doesn't matter how big or small, after a while, LibreOffice runs up its CPU usage to around 100%, the fan is running all the time, battery is draining quickly.

My laptop is Lenovo G570, Intel i5-2430M.

Is there a way I can find out what LO is actually doing to help debug it?

LO 6.1.2.1 on macOS 10.13.6 

Still getting this on various documents - as well as general slowness on documents that don't spin to 100% CPU usage (see https://bugs.documentfoundation.org/show_bug.cgi?id=120727).

Not quite sure how I can help debug - can send process samples and was able to isolate and upload a document for 120727.

The documents that pertain to this bug are work documents that cannot be shared unfortunately.

The documents that give me problems are, AFAIK pure .odt documents as well (i.e. have never been through docx)

@laurens : if you can't provide us the problematic documents due to confidentiality issues - which we fully understand of course, can you provide us some information on the structure of the document :

 - page formatting ?
 - number of pages - forced page breaks or natural pagination ?
 - tables; if any, with examples of structure of table ?
 - images : type, format, resolution, anchoring - framed or not ?
 - any legends or numbering for the illustrations ?
 - document, page, heading, font styles used ?
 - automatic spellchecking - langpacks ?

I will try to make a redacted version that exhibits the problem as I understand how hard it would be to debug this otherwise. As the bug (high CPU usage when idle) takes an indeterminate amount of time to appear (1-60+minutes) it may take a few days before I can create & test this.


I don't know if it is related to the other bug I have regarding high-CPU usage when typing if graphics objects are Anchor: To Paragraph (rather than as character) https://bugs.documentfoundation.org/show_bug.cgi?id=120727

Cross post with Bug 120727, as this look similar:

Hello,

i had the same problem as laurens with older version of Libreoffice, i uninstalled and reinstall last version and same problem again:

even only scrolling a simple document with text (and with the example of laurens as well in Bug 120727) is a nightmare: so slow.

Version: 6.2.0.3
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 4; OS: Mac OS X 10.14.3; UI render: default; VCL: osx; 
Locale: fr-FR (en_FR.UTF-8); UI-Language: en-US
Calc: threaded

Computer:

  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro13,1
  Processor Name:	Intel Core i5
  Processor Speed:	2 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	4 MB
  Memory:	8 GB
  Boot ROM Version:	228.0.0.0.0
  SMC Version (system):	2.36f97




When scrolling, MAC OS activity monitor shows at least 60% use of CPU, up to more than 100% in a few seconds of scrolling.

Degrading to right click in libreoffice.app and"get info, low resolution" is better but still slow; and ugly.


Thanks for help!

Hello,

still same problem with new version of Libreoffice

Version: 6.2.2.1
Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01
CPU threads: 4; OS: Mac OS X 10.14.3; UI render: default; VCL: osx; 
Locale: fr-FR (en_FR.UTF-8); UI-Language: en-US
Calc: threaded


The problem is happening with Libreoffice Impress /  presentation as well.


Thanks

I can confirm this behaviour. I just found it out when I was working on another computer while LibreOffice Writer was opened, but was idle. After a few minutes, the CPU went to 100%.

The document was a selfmade template of a package slip and had a OLE-object in it (Calc). I tried the same routine by leaving the computer in idle with a new LibreOffice Writer document, and in idle, LibreOffice behaved. I tried it again with a new, empty Writer document and added an empty OLE-object. And yes, after a few minutes the CPU went through the roof again.

I also checked of this behaviour was the same in Calc, but Calc itself didn't trigger the CPU. When in idle for a while, nothing happened.

Behaviour was on Xubuntu 18.04.2 on a 32-bits machine.

I forgot to mention to mention which version of LibreOffice I used. I used LibreOffice 6.2.2.2., Build-ID: 1:6.2.2.-0ubuntu0.18.04.1~lo1.

Created attachment 151278 [details]
Example file exhibiting behavior

This is an example file showing the 100% CPU utilization bug.  This will completely hang 6.0.x on Ubuntu for several minutes before it eventually displays.  Converting it using lowriter --convert-to to an ODT then opening it in an interactive session will hang 6.0.x indefinitely on a SandyBridge era Intel Core i5 2400S CPU.  Converting the same file to a PDF then viewing it takes a trivial amount of time (using lowriter --convert-to takes seconds to convert then display in a PDF viewer).  On a Dell laptop with an i5 8300H on Windows 10 with LO 6.2.3.2 AMD64 it still takes several minutes to display with the CPU pegged to 100%, but it will eventually do so and you can close it without hanging LO.

As a follow up to my last post, I upgraded my Kubuntu installation's LibreOffice to 6.2.3.2 (AMD64) from the LibreOffice.org packaged debs and opening that file with that version opened it normally without hanging at high utilization.  I have no idea why it's different between the Win 10 version and the Linux version on that particular file, but I'm seriously getting pissed with all the problems on Windows 10!

To be clearer:  the example .doc file seems to open fine in Kubuntu v 18.04.2 Linux but takes minutes in Windows 10 using the same version of LO 6.2.3.2 which seems stop responding with 100% utilization on one core.

Hello all,
this is a duplicate of bug 122207.
If you are suffering this problem, please use LibreOffice 6.1.6.3 or 6.2.3.2
Closing as RESOLVED DUPLICATED

*** This bug has been marked as a duplicate of bug 122207 ***

Hello Xisco;

maybe i'm missing something but why resolved ?

in calc: 

i just tried with fresh install of

Version: 6.2.3.2
Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac
CPU threads: 4; OS: Mac OS X 10.14.4; UI render: default; VCL: osx; 
Locale: fr-FR (en_FR.UTF-8); UI-Language: en-US
Calc: threaded

with mac os  mojave 10.14.4 (18E226)
Model Name:	MacBook Pro
  Model Identifier:	MacBookPro13,1
  Processor Name:	Intel Core i5
  Processor Speed:	2 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	4 MB
  Memory:	8 GB
  Boot ROM Version:	231.0.0.0.0
  SMC Version (system):	2.36f97

and it still lags !

Only not satisfying solution is to check "open in low resolution"...

I will post in bug 122207 as well.

*** This bug has been marked as a duplicate of bug 122207 ***

Hi - I don't know why this is marked as resolved or why it was marked as duplicate to another bug.

I'm still getting this 100% CPU usage after having work documents open for a while (with a lot of OLE objects).

The issue is sometimes temporarily resolved if I scroll up and down through the complete document. But after a few minutes the fans kick in again and LO is processing 100% whilst idly displaying my document.

Version: 6.2.4.2
Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU threads: 12; OS: Mac OS X 10.14.5; UI render: default; VCL: osx; 
Locale: nb-NO (en_NO.UTF-8); UI-Language: en-US
Calc: threaded

I can't reproduce it in

Version: 6.4.0.0.alpha0+
Build ID: 6d024a69164716f7856ec936a72d01a6630d2a7c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES-valencia (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

MAC only ?

What the behaviour in LibreOffice 6.3.0 to be released today?

Still a dealbreaker for me in 6.3.1.2 :/ Using mainly macOS on a 2018 retina Macbook Pro. Note I deleted my user profile yesterday, so this is completely fresh, no extensions.

Just downloaded the latest LO RC (needed to get the trackpad reverse scrolling fix)

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

My work documents still jump to 100% CPU and eats my battery.
They contain graphics (anchor as character, because to Paragraph causes huge CPU usage and lag, see 120727). Also tried deleting Header and Footer, but that did not seem to change things. 

NOTE: CPU drops to 0% whilst one of the LO Pull Down menus is open.

I have a sample shot of the LibreOffice Process from Mac Activity Monitor - attaching a PNG that shows the calls that it seems to spend a LOT of CPU time in. I don't know if that helps anyone narrow it down?

Created attachment 153833 [details]
Sample screenshot showing time in function calls when 100% CPU

When the 100% core usage (In reply to laurens from comment #31)
> Created attachment 153833 [details]
> Sample screenshot showing time in function calls when 100% CPU

When the 100% usage occurs, then:

Tools -> Update -> Update All 

Seems to fix it for a while (View -> Web also prevents it from happening, but is not a solution for general use)

Still a problem with 6.2.7.1
Version: 6.2.7.1
Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf
CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: nb-NO (en_NO.UTF-8); UI-Language: en-US

Still a temporary solution (for a few minutes) is:
Tools -> Update -> Update All 

I don't have a simple document to share that is not work related, but the https://bugs.documentfoundation.org/attachment.cgi?id=153833

shows what is eating up CPU cycles.

Anyone looking into this or any other way I can provide more useful information (apart from the screenshot and the temporary solution, which should help in figuring out where the problem lies)?

Here, laurens with Mac never attached a sample.
raroru confirmed for Mac (but it has a number of other issues).
Eltomito and Margeaux confirmed for Xubuntu, which doesn't have to be the same. 

ross is the only one who attached 3-pages DOC so it can be tested.
But I conclude it was fileopen problem. Yes 1st start was slow, bug 131545. 
I don't see a high CPU problem in LO 7.4+ (we test with master). 

Each bug report makes sense only if actionable, with repro steps.
General rules are: search in existing bugs before repoting, attach a minimal sample (if personal, replace all chars with x). 

This one can only be closed. 
If you still have a problem, please search in Mac bugs and if reported, follow https://wiki.documentfoundation.org/QA/BugReport and attach a minimal sample.