Bug 100139 - Can't work on specific docx file with tracked changes visible (specials fonts, two huge tables..)
Summary: Can't work on specific docx file with tracked changes visible (specials fonts...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx, perf
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2016-05-30 12:51 UTC by Levan
Modified: 2023-05-16 09:37 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
docx file (1.53 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-05-30 12:51 UTC, Levan
Details
perf flamegraph (238.12 KB, application/x-bzip)
2020-03-24 18:13 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Levan 2016-05-30 12:51:39 UTC
Created attachment 125390 [details]
docx file

I noticed that it was impossible to work on certain .docx file.
Well libreoffice opens it but it hangs and basically it is unusable  

I even tried to export this file as open document but still same issue.

I am attaching the docx file.
Comment 1 MM 2016-05-30 18:33:45 UTC
Confirmed with v5.2.0.0a1 under ubuntu 16.04 x64.
Comment 2 Cor Nouws 2016-05-31 08:36:22 UTC
Thanks for reporting Levan.
I confirm the problem in daily20160525 on Ubuntu 32 bits.

Loading takes long ; working in the document not possible.

Writer continuously fights with the page count. Looks as if a/the table(s) have something to do with it.
I see there is change tracking too in the document. Turning of showing the changes (waiting...) makes that the file is editable..
But then SaveAs takes a huge time again...
Opening in 3.3.0 is a pain too.
Comment 3 Cor Nouws 2016-05-31 08:36:43 UTC
thus new
Comment 4 QA Administrators 2017-12-10 16:41:47 UTC Comment hidden (obsolete)
Comment 5 Cor Nouws 2017-12-28 22:39:51 UTC
still the same problem in 
Version: 6.1.0.0.alpha0+
Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-26_23:09:36
Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded
Comment 6 QA Administrators 2018-12-29 03:49:53 UTC Comment hidden (obsolete)
Comment 7 Cor Nouws 2019-01-20 21:51:22 UTC
unchanged in 6.3 master
Comment 8 Xisco Faulí 2020-03-24 09:29:27 UTC
Hi Julien,
would it be possible to have a perf graph for this issue ?
Comment 9 Xisco Faulí 2020-03-24 11:55:57 UTC
it seems it takes much longer to open it in master than in the past

Version: 7.0.0.0.alpha0+
Build ID: fd1cd5522283f279a01d6d673f676a1346e9358b
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 10 Julien Nabet 2020-03-24 18:13:53 UTC
Created attachment 158953 [details]
perf flamegraph

Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
After more 30 secs, the document still wasn't loaded (Ryzen 2600, 32Gb)
Comment 11 Xisco Faulí 2020-03-24 18:39:24 UTC
Using 'time OOO_EXIT_POST_STARTUP=1 instdir/program/soffice' it takes

real	3m58,908s
user	3m57,239s
sys	0m1,646s

in

Version: 7.0.0.0.alpha0+
Build ID: fd1cd5522283f279a01d6d673f676a1346e9358b
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

and

real	1m38,501s
user	1m37,409s
sys	0m1,048s

in

Version: 6.4.0.0.alpha1+
Build ID: 9bc848cf0d301aa57eabcffa101a1cf87bad6470
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

will report it in another issue...
@Julien, thanks for the perfgraph
Comment 12 NISZ LibreOffice Team 2021-04-02 09:42:41 UTC
I can't reproduce the runtime slowness in newer versions.
The redlinehide work seems to have solved that part around 6.2.

Now fileopen got worse because of the regressions bibisected in bug #131546 and bug #136227 but once opening is finished and all pages are rendered, Writer is responsive to scrolling and editing, just as reported in bug #101149 comment #15.
Comment 13 Roman Kuznetsov 2022-05-25 09:39:04 UTC
If accept all tracked changes in the document, save and close it and then try open it again, then LO opens it much faster

Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: b6266207b55a7633dc82b02142215757512adfb7
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded
Comment 14 Gabor Kelemen (allotropia) 2023-05-16 09:37:58 UTC
Opening time was reduced a bit in 7.4.5 with

https://git.libreoffice.org/core/+/3998b98749739b2c499ffc4d83188e1034b66750

author	Miklos Vajna <vmiklos@collabora.com>	Mon Dec 19 08:47:18 2022 +0100
committer	Mike Kaganski <mike.kaganski@collabora.com>	Thu Dec 22 06:12:45 2022 +0000

sw: ODT import/export of DOCX's paragraph marker formatting

from 
$ time OOO_EXIT_POST_STARTUP=1 isw --norestore 1\(1\).docx

real    3m5,483s

to

$ time OOO_EXIT_POST_STARTUP=1 isw --norestore 1\(1\).docx

real    2m13,181s

and in recent bibisect-7.6 master:
$ time OOO_EXIT_POST_STARTUP=1 isw --norestore 1\(1\).docx

real    1m25,240s

But there is probably still room for improvement, even with the 6.4+ regressions gone :).