We have the same problem on a LO 3.5.5 installation.

The other Bug 60418 talks about huge memory consumption and CPU usage WHILE opening a complex document. This was even due to the presence of 'form:form' tags in the content.xml.
This bug speaks about huge performance peaks while EDITING the document, after it has been opened just fine.

Thanks for your clear reply.

(In reply to comment #4)
> This bug speaks about huge performance peaks while EDITING the document,
> after it has been opened just fine.

I can confirm that behavior using Linux Mint 14 x64 and LibreOffice Version 4.1.0.0.alpha0+ (Build ID: 5fcb553c862d407aadb0320925723d3c2f70bfe).

Kind regards,
Joren

(In reply to comment #7)
> Anyone?

Hi,

I'm sorry, I didn't saw your question. I think these 2 emails will be interesting to read: http://lists.freedesktop.org/archives/libreoffice/2013-February/045455.html and http://lists.freedesktop.org/archives/libreoffice/2013-February/046372.html

As mentioned there, you can contact existing consulting company like:

* Lanedo (http://www.lanedo.com/libreoffice.html)
* Credativ (http://www.credativ.com/)
* Codethink (http://www.codethink.co.uk/)
* Collabora (https://www.collabora.com/)

and individual certified developers (they are working on a list).

I hope this is an answer to your question?

Kind regards,
Joren

And of course SUSE and others provide support & consultancy :-)

I can confirm this issue in LibreOffice 4.0.2.1 on Fedora i686.

I have been experiencing this on some of my documents also and I have discovered something that may help in locating the problem.  I tried it with the sample document attached to this bug and it worked for it also.  Go to the View menu and toggle the "Hidden Paragraphs" option.  Evidently this causes it to halt whatever loop it is stuck on.  This is not a permanent solution as my documents started to respond slowly again after a time and then I needed to toggle the option again.  To force it to exhibit the problem all one needs to do is to go to the Tools menu and select Update - Update all.  An extreme lag when doing any typing will be immediately noticed which can then be fixed by toggling the "Hidden Paragraphs" option again.  It doesn't matter if the option is initially enabled or disabled.  The lag will occur with it either way and the document will start responding again when it's toggled.

I would assume this bug is related to bugs 59714 and 58029 which were fixed.  Bug 56963 may also be affected by this but I haven't been able to test it because the sample document seems to be no longer available.

I believe this bug is a duplicate of bug 60418 in which the "Update All" and the "Hidden Paragraphs" commands exhibit the same behavior as they do for this bug.

Using attached file, I can scrolling up & down fast enough (though there is little lagging). No halt when toggle off Hidden Paragraph, & no crash at all. 

Using 'only' 1.3GB dual Pentium processor with 2GB ram (LO 4.0.4.2 Win7 32bit).

@Giorgio/Have you tried latest stable release & resetting user profile?

@ign_christian : no, haven't tried yet with latest stable release.
One specific behaviour though was, apart from the small lag, the memory consumption of soffice.bin kept growing and growing just by using the scrollbar. And if you keep doing this long enough (several minutes), the memory consumption became so high that eventually LO crashed (going over 1.x GB (32-bit)).
Can you confirm the ever-increasing memory consumption by just using scrollbars?

Yes increasing slightly, I think it's not significant. 
No huge increasing like Bug 62768.

If using Windows, I suggest to do regularly defragmenting together with some registry & file cleaning. I believe it gives significant result :)

Increasing 'slightly' a second, BUT constantly by small amounts just by using the scrollbar, until, after having worked for hours on the document and having used the scrollbar a lot, it reaches more than one GIGABYTE and finally an APPCRASH occurs. I don't see how this is insignificant....

It is an unusual problem; the document has no large images in it (that I can see) which would be the obvious causes of leaks.

If someone has a build with symbols they can reproduce this in, then running under valgrind like this:

cd /path/to/program
export OOO_DISABLE_RECOVERY=1
valgrind --leak-check=full --show-reachable=yes --leak-resolution=high soffice.bin -writer >& /tmp/val-log

please be aware this will run 80x slower or so; when it's done (do a bit of scrolling etc.) then gzip and attach the /tmp/val-log

Hopefully that shows us where the issue is quite easily :-) NB. you need a build with symbols [ on a distro just installing the debuginfo prolly does it ].

Thanks !

And remember also that lags which cause increased cpu usage can be triggered by going to Tools | Update | Update All when View | Comments is enabled.  The extreme lag will be immediately noticed when typing anything into the document.  The lag can then be caused to disappear by toggling the View | Hidden Paragraphs option either on or off.

Hi all,

tested and I can confirm the described behavior: Opened test file in LO 4.3b1, grab scrollbar and move it up and down constantly. Activity monitor on OSX shows CPu usage going to 100%. If I let go of the scrollbar, CPU usage normalizes.

This is a document with lots of comment. So it's for Devs to decide wether this CPU usage is expected and "normal" or if this needs fixing.

From QA side at least, I can set this to NEW.

With version 4.2.4 under linux I see nothing abnormal anymore when trying to scroll.  But there still is an EXTREME lag when trying to type anything into the document as exhibited when perfoming the actions described in an earlier post.

I have the same issue, especially with documents containing (not so) large immages. 
Affects .odt as well as .doc and .docx
The lag is far more evident when the incriminated immage is visible.
Not all immages cause the problem.

LO 4.2.3 and 4.2.2 on Ubuntu 12.04 on a HP 255 laptop

With LO Versión: 4.3.4.1 Id. de compilación: 430m0(Build:1) I`m editing a file of 224 pages and lots of tables and it freezes constantly, it keep using 100% of one cpu core, and quit of responding even after several minutes. So I must kill LO and reopen the document with the correspondent recuperation and lost of work.

Suffering same problem with LO 5.1.3 on Linux Lite 2.8 (ubuntu derivative) x64, system fully updated.

Any file of any larger size will freeze on normal operations such as find/replace all paragraph endings. CPU typically goes to 49%, which doesn't sound too bad, but the program freezes. This is happening on a simple .odt file of 1.7MB size.

Have had this problem since Day One on this system, using several versions of LO.

Machine is 2.7 GHz Core2Duo with 4gb ram and an SSD. Should not be a problem.

This has been a problem since staroffice and possible. solved by minimizing the number of graphic elements loaded at startup of a document. For pages that are not plus minus 10 pages from the image on the screen.

This is a problem on all platforms including Windows 7, 8, 10.

Took a look. What seems very expensive are the comment visualizationms at the right. Switching these off makes all much better/responsive. I could not reproduce the ever-growing mem consumtion and not the crash, may be that a mem leak we had is already fixed.

Testing in Version: 5.2.0.0.alpha0+
Build ID: 5a4b01f63d3f2a7d7d6fa8cf9ca6a328c5da7a6a
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-04-08_03:26:11
Locale: nl-NL (nl_NL.UTF-8)

- after some scrolling ~constantly uses full cpu (one core)
- after killing, turning off Tools > Options > Writer > View .. Comments
  I can do with the file what I want.

@GiorgioMigliaccio all the comments.. looks as a paste from html?
Or what about all the locked text frames.. Anyway: special document :)

Yes, special document, but the comments - rendering/creation/handling seems too expensive. Would be worth a look.

Did some evaluation and indeed the comments are quite expensive currently, they seem unnecessarily often to be created/layouted and positioned, most probably without even being visible. Would require some work, but could definitely be enhanced...

This seems it was not possible to tackle by volunteer developers. So to update on Joren's (and others) comments, there's a thriving ecosystem of LibreOffice support companies now; a list of those with certified developers is linked here:

http://www.libreoffice.org/get-help/professional-support/

FWIW, ballpark number for fixing this is around one week of work ...

Dup of bug 97698?

*** Bug 120102 has been marked as a duplicate of this bug. ***

(In reply to Cor Nouws from comment #30)
> Testing in Version: 5.2.0.0.alpha0+
> Build ID: 5a4b01f63d3f2a7d7d6fa8cf9ca6a328c5da7a6a
> CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
> TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-04-08_03:26:11
> Locale: nl-NL (nl_NL.UTF-8)
> 
> - after some scrolling ~constantly uses full cpu (one core)
> - after killing, turning off Tools > Options > Writer > View .. Comments
>   I can do with the file what I want.
> 
> @GiorgioMigliaccio all the comments.. looks as a paste from html?
> Or what about all the locked text frames.. Anyway: special document :)

Can everyone please try with a fresh build or 6.2? Michael Stahl has done some work in this area and I confirm that I cannot get LibO into the state described by Cor above.

We have various reports for general bad perf regarding comments: https://bugs.documentfoundation.org/buglist.cgi?keywords=perf%2C%20&keywords_type=allwords&list_id=911413&query_format=advanced&resolution=---&short_desc=comments&short_desc_type=allwordssubstr

Hopefully we can close this one?

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: a2a762a9b6cad4ab0bb1b71b99aebc8c047c94d0
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 14 February 2019

(In reply to Buovjaga from comment #41)
> Can everyone please try with a fresh build or 6.2?

I opened sample document from initial bug report without any problems (3 or 4 seconds and CPU usage around 40% during that time). 

Version: 6.3.0.0.alpha0+ (x64)
Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

So I would say RESOLVED WORKSFORME.

This still still holds: "using the page scrollbars constantly, or using page-up page-down keys make the CPU usage go to 80-100%" (comment 0)

Same for comment 32 & comment 34. However, the title should be rephrased, because
1. The memory issue is long gone.. 
2. The performance of tracking changes has improved 

Comment 32 and 34 are still adequate (see also bug 60418  bug 119485, bug 122971, bug 122969.. which have all the same root-cause)

I personally would  rephrase the title leave this one open, and close the rest..

*** Bug 60418 has been marked as a duplicate of this bug. ***

*** Bug 119485 has been marked as a duplicate of this bug. ***

*** Bug 122971 has been marked as a duplicate of this bug. ***

*** Bug 122969 has been marked as a duplicate of this bug. ***

Callgrind traces in bug 60418 and bug 122969

*** Bug 92011 has been marked as a duplicate of this bug. ***

(In reply to Buovjaga from comment #48)
Callgrind traces in bug 60418 and bug 122969 & bug 92011 comment 7

Some notes from my unsucessful attempt to fix this:

(1) I can fix the typing part by removing the WB_DIALOGCONTROL flag from the SwEditWin constructor. The time is being spent searching through tons of child windows on every key stroke. I don't think this flag is necessary because we're not doing dialog things in the main window.
But I'm probably wrong and there is some weird reason we need it.

(2) I can fix the paging/scrolling part by commenting out the 
     if ( pPostItMgr ) // #i88070#
     {
        pPostItMgr->Rescale();
        pPostItMgr->CalcRects();
        pPostItMgr->LayoutPostIts();
     }
code in void SwViewShell::VisPortChgd
As far as I can tell, the UI still works fine without those lines of code, because don't actually need to run the bulk of layout when the viewport changes.

According to the bug report in the comment
    https://bz.apache.org/ooo/show_bug.cgi?id=88070
they are there because accessibility stuff is being calculated during the layout loop. So one possible fix would be to pass some sort of flag down to CalcRects and LayoutPostIts to say "only do the accessibility stuff"

Created attachment 151939 [details]
Example file

I have 4 CPU at my computer.

With attachment from comment 53
CPU 4 100% for 25 seconds
After that I was scolling the document and all 4 CPU were at 20-30%
When closing again CPU 4 at 100% for 20 seconds.

Tested with
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 5aa74aa1e6fac571f99146ebcb6adc9feb1459ad
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-28_19:35:14
Calc: threaded

Much better on
Version: 7.3.0.0.beta1+ (x64) / LibreOffice Community
Build ID: 8c137ff0e201c2d0ecd1bb567496dbed8e5eced7
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: ro-RO (ro_RO); UI: en-US
Calc: threaded

No 100% on CPU. Maximum at 80% for short time.
200 MB memory and remaining there.

Please retest.

attachment 151939 [details] is still very laggy, but attachment 75642 [details] is quicker. Both use a bit over 50% CPU, though.

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded

"Sample Document" is still in the 85% range while scrolling for me. Memory usage starts at about 931.4 MB just after the document is opened, then keeps growing as I scroll.

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: e9332dcdc8f2ea268d1b17c73d43a8834cf75365
CPU threads: 10; OS: Mac OS X 12.0.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

It seems the problems are on Linux and Mac OS. Not Windows.

attachment 151939 [details] still somewhat laggy in the latest commit of Linux 7.4 bibisect repo, but the oldest of 7.3 repo is certainly much worse, like freezing. Therefore I think we can lower priority and severity.

Version: 7.4.0.0.beta1+ / LibreOffice Community
Build ID: cdf48e57da6b8a6a5eb4131340fa2c14be135714
CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded

*** Bug 155776 has been marked as a duplicate of this bug. ***

*** Bug 113867 has been marked as a duplicate of this bug. ***

repro 24.2+
Memory climbs (slowly, but constantly) when holding page-up to scroll. Scrolling is definitely not fast.