Bug 126344 - Undo is slower and consumes more CPU time after pressing undo (compared to 6.1)
Summary: Undo is slower and consumes more CPU time after pressing undo (compared to 6.1)
Status: RESOLVED DUPLICATE of bug 116400
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression, wantBacktrace
Depends on:
Blocks: Undo-Redo
  Show dependency tree / graph
 
Reported: 2019-07-11 13:23 UTC by Telesto
Modified: 2022-02-10 11:06 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-07-11 13:23:44 UTC 
Description:
Undo is slower and consumes more CPU time after pressing undo (compared to 4.4.7.2)

Steps to Reproduce:
1. Open attachment 140185 [details]
2. Press F5
3. Go to page 200
4. Set cursor at the beginning of pag 200
5. Press Shift & scroll to the bottom and select the end of the sentence (ergo select everything from pag 200 until end)
6. Press Delete (wait until the CPU usage is down to nearly zero)
7. Press Undo (CTRL+Z

 

Actual Results:
30 seconds CPU spike after press undo. It's slower and more CPU hogging

Expected Results:
12 seconds spike in LibO 4.4.7.2 (comparison is bit off.. scheduling has changed.. everything is processed on 'high priority'.. previously the scheduling had more of idle way of doing things.. but it's to slow for sure.. Maybe large paragraphs issue


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-07-10_00:49:53
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Dieter 2019-07-11 17:17:10 UTC 
I confirm it with attached document

Around 30 sec in

Version: 6.4.0.0.alpha0+ (x64)
Build ID: ae823e4633a76d13cebc6432b9e44b9b2862326b
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-26_23:06:07
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded



and around 17 sec in

Version: 5.4.7.2 (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 2 Buovjaga 2020-06-08 19:26:35 UTC 
Bibisected with win32-6.2 to https://git.libreoffice.org/core/+/86dfa34c6d83b70923d462fecad316dafd9a1fc4%5E!/
Upgrade to ICU 62.1

So "nobody's fault". I also checked and automatic spellchecking does not have an effect on/off.
Comment 3 Timur 2022-02-10 08:22:24 UTC 
Why make 3 bugs out of 1?

*** This bug has been marked as a duplicate of bug 116400 ***
Comment 4 Dieter 2022-02-10 10:33:41 UTC 
(In reply to Timur from comment #3)
> Why make 3 bugs out of 1?
> 
> *** This bug has been marked as a duplicate of bug 116400 ***

Bug 116400 is about PDF-generation. So are you sure, it's the correct bug for a duplicate?
Comment 5 Telesto 2022-02-10 11:06:53 UTC 
(In reply to Dieter from comment #4)
> (In reply to Timur from comment #3)
> > Why make 3 bugs out of 1?
> > 
> > *** This bug has been marked as a duplicate of bug 116400 ***
> 
> Bug 116400 is about PDF-generation. So are you sure, it's the correct bug
> for a duplicate?

I think Timur being right here.. The difference is only how the problem is triggered, the underlying problem is the same. And the same file.. Same bibisect result..