Bug 120738 - Unresponsive .odt document when switching to webview & high CPU usage, also dump VCRUNTIME140!FindMITargetTypeInstance
Summary: Unresponsive .odt document when switching to webview & high CPU usage, also d...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Writer-Web-Layout CPU-AT-100%
  Show dependency treegraph
 
Reported: 2018-10-20 18:00 UTC by Telesto
Modified: 2021-01-15 20:20 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-10-20 18:00:35 UTC
Description:
Unresponsive document when switching to webview & high CPU usage

Steps to Reproduce:
1. Open attachment 145863 [details]
2. Switch to webview -> monitor CPU usage
3. Make some edits to for the experience

Actual Results:
High CPU usage and slow

Expected Results:
Better performance


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 6.2.0.0.alpha0+
Build ID: b63d48a146c3615f56b6ec83361b3c02ebcbb215
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-13_23:33:20
Locale: nl-NL (nl_NL); Calc: CL

Versie: 4.1.0.4 
Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace2
Comment 1 Jean-Baptiste Faure 2018-10-20 20:08:34 UTC
Not sure if there is a bug: switching to webview require a lot of changes in the layout, only 7 pages, note numbering to redo. When the document is ready to edit, I do not experience any lag when modifying the text.

Version: 6.2.0.0.alpha0+
Build ID: aa3b2f90a62678c8e594830277a32e3ad742e826
Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; 
Ubuntu_18.04_x86-64
Locale : fr-FR (fr_FR.UTF-8); Calc: threaded

Best regards. JBF
Comment 2 Telesto 2018-10-22 18:00:51 UTC
It's very slow. Processing takes surely 4 minutes on Windows (probably more)
Version: 6.2.0.0.alpha0+
Build ID: 3846561f79cf9065abd9ca83c9fbfbe7e52e28e2
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-20_23:33:00
Locale: nl-NL (nl_NL); Calc: CL
Comment 3 Weng Jing-Yao 2018-11-29 09:38:15 UTC
Bug confirmed.

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded

it's slow but the processing only take few (usually 3-5)seconds.
Comment 4 Timur 2018-11-29 11:49:11 UTC
I confirm. If opened with procdump, dump can be seen:
VCRUNTIME140!FindMITargetTypeInstance+0x96:
Not sure how WinDbg can be used when Win-x86@39 is down.
Comment 5 Roman Kuznetsov 2018-12-27 20:54:47 UTC
Mike, can you say anything about this?
Comment 6 QA Administrators 2020-12-27 03:37:14 UTC Comment hidden (obsolete)
Comment 7 Roman Kuznetsov 2021-01-15 20:20:46 UTC
still repro in

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 94f6765d6ecc3145fa2d266231124003cf953118
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL