Description: 45 seconds processing when adding 5 pages to large 817 pag doc with 4000 footnotes (SwFootnoteBossFrame::CollectFootnotes_ Steps to Reproduce: 1. Open the attached file (source: bug 130822) 2. Press CTRL+Enter 5x notice 45 seconds of CPU processing Actual Results: 45 seconds of background processing Expected Results: Somewhat more resource friendly? Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x86) Build ID: 9af38b4504ccda57a0c32eb8bdd03e5a8ca29ddc CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in 4.4.7.2 (or at least not in this way) Idle stuff (as bibisected before)
Created attachment 162764 [details] Example file
Created attachment 162765 [details] BT with symbols VTune Profiler based on x39 build
*** Bug 134081 has been marked as a duplicate of this bug. ***
Created attachment 162772 [details] Example file Another example 1. Open the attached file 2. Insert -> Table of content -> Table of contents 3. Press OK and start waiting (can take 2 minutes or so) 4. If you like waiting.. press CTRL+Z 5. Press CTRL+Y -> RuleBasedBreakIterator + Footnotes Of course as nice idle process.. so you can keep editing..
Another way 1. Open the attached file 2. CTRL+A (3x) 3. CTRL+X 4. CTRL+Z -> should cause SwFlyFrame::ResetNotifyBack swlo [unknown] 0 0x7ffeca048aed SwFlyFrame::ResetNotifyBack swlo [unknown] 0 0x7ffeca048719 SwLayoutFrame::MoveLowerFootnotes swlo [unknown] 0 0x7ffeca04c051 5. Update index to get a proper page count -> could cause it again
Created attachment 166907 [details] Example file
Please see if affected by fix in bug 76260.
No improvement Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f96004096268f5e71120678e32fc8c74055819aa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
I actually think it god worse, it loops now @NISZ They hope was commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 making a difference here (opening is fine, but the reported issue is still present). However I think it got worse since my report (it really doesn't stop.. or taking very long time). Many possibility's why (Bjoern (SwModify::~SwModify), Lubos (font buffering), Stahl (layout loop control), László (Improving footnotes). C++ EH exception - code e06d7363 is done over and over (but no clue what it means) Once a while warnings come along: warn:sw.core:5448:3544:sw/source/core/docnode/node.cxx:1980: Wrong cond collection, skipping check of Cond Colls. warn:legacy.osl:5448:3544:sw/source/core/layout/flowfrm.cxx:2561: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applie warn:legacy.osl:5448:3544:sw/source/core/layout/ftnfrm.cxx:1873: _CollectFootnote: Master expected It does work 'perfectly' fine as background process (so typing and such is smooth), but this is surely a battery drain :P. Seeing 100% CPU usage (single core) for 4 minutes.. (it doesn't look like a timer glitch to me)
Repro with attachment 162764 [details]. Tested with Linux 7.4 bibisect repo. It indeed seems to be the idle rework. I tested with Linux 50max repo and in source commit 01f406bc28f53acc5a2734af637aa8074a5d1813 it does not hit the CPU like it hits after the bibisect commit containing multiple ones (including the idle rework). I couldn't run the bibisect commit with the range of commits, but this source commit showed the problems: 01f406bc28f53acc5a2734af637aa8074a5d1813 Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: cfd82e7a2cc2b45b738eb0efa0827196d2de61a4 CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded