Description: i am a novel writer, and i am about to EDIT my novel. 720 pages 1.8M characters 308K words in total. Here is a Youtube Video about it to MADE it clear: www.youtube.com/watch?v=mSW_7zZPQcU Steps to Reproduce: 1. start Libreoffice WRITER 2. load BIG ODT file with pictures 3. wait a DECADES to edit with writer. Actual Results: WERY slow loading time Expected Results: normal, or FAST loading speed. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: my rig is: I7 990x amd Hd 69** my os is : Linux Mint 17.3 ( 64bit )
Created attachment 144018 [details] file size limit 30 MB ? why ? this is the MAX size of ODT size allowed ? HUNGARIAN (hard sci fi) novel, similar to the star wars universe, but this is a gunslinger hero space pirate with his adventures. 22 MB in size. ( and yes, 30 MB is the limit (???) )
Repro with Version: 6.2.0.0.alpha0+ Build ID: 1b21ff86effe58ae368457de8fec654ba4c8edd9 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-07-30_03:13:35 Locale: nl-NL (nl_NL); Calc: CL but not with Version: 5.4.1.0.0+ Build ID: f200d5700782ae179fd96b6ad4b0fe8e7edd1616 CPU threads: 4; OS: Windows 6.29; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=e6b200524bd5f614ab5ece88e8187466e7c40096 author Ashod Nakashian <ashodnakashian@yahoo.com> 2017-11-02 21:20:50 -0400 committer Ashod Nakashian <ashnakash@gmail.com> 2017-11-06 06:12:21 +0100 commit e6b200524bd5f614ab5ece88e8187466e7c40096 (patch) tree c90e7c8d45f353a43465aa8c43e9881d4d55d53f parent ffa46ebe6d83c5e812753c41857f31c059f33986 (diff) TSCP: Store paragraph signature RDF in the paragraph Bisected with: bibisect-linux64-6.0 Adding Cc: to Ashod Nakashian before this commit it takes real 0m6.048s user 0m4.676s sys 0m0.416s and after real 0m57.413s user 0m56.213s sys 0m0.312s
in Version: 6.2.0.0.alpha0+ Build ID: c86a47a9d3debbc7e8ee6247f573e7f98c611f19 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded and Version: 6.0.0.0.alpha1+ Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded it takes real 2m49.855s user 2m48.125s sys 0m0.644s so it needs a second bisection between e6b200524bd5f614ab5ece88e8187466e7c40096 and the latest commit in bibisect-linux64-6.0, will do it later...
I tried to bisect it again but I couldn't find any place where the difference is as clear as the one mentioned in comment 3 where there's a jump from 6 seconds to 1 minute...
trying out on LATEST KDE ubuntu 18.04, and installed a Libreoffice PACK on it. Libreoffice version is : 6.0.6.2 ubuntu build: 1:6.0.6-0ubuntu0.18.04.1 The loading time is the same, around a minute, using the SAME ODT file ( my novel )
Created attachment 144053 [details] Valgrind core dump I tried to get a callgrind trace of the opening, but it failed immediately vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x55 0x48 0x89 0xE5 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 ==3503== valgrind: Unrecognised instruction at address 0x4002e10. ==3503== at 0x4002E10: ??? (in /usr/lib/ld-2.28.so) ==3503== by 0x4002007: ??? (in /usr/lib/ld-2.28.so) ==3503== by 0x2: ??? ==3503== by 0xFFF000742: ??? ==3503== by 0xFFF00076A: ??? ==3503== by 0xFFF000787: ??? ==3503== Your program just tried to execute an instruction that Valgrind ==3503== did not recognise. There are two possible reasons for this. ==3503== 1. Your program has a bug and erroneously jumped to a non-code ==3503== location. If you are running Memcheck and you just saw a ==3503== warning about a bad jump, it's probably your program's fault. ==3503== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3503== i.e. it's Valgrind's fault. If you think this is the case or ==3503== you are not sure, please let us know and we'll try to fix it. ==3503== Either way, Valgrind will now raise a SIGILL signal which will ==3503== probably kill your program. ==3503== ==3503== Process terminating with default action of signal 4 (SIGILL): dumping core ==3503== Illegal opcode at address 0x4002E10 ==3503== at 0x4002E10: ??? (in /usr/lib/ld-2.28.so) ==3503== by 0x4002007: ??? (in /usr/lib/ld-2.28.so) ==3503== by 0x2: ??? ==3503== by 0xFFF000742: ??? ==3503== by 0xFFF00076A: ??? ==3503== by 0xFFF000787: ???
(In reply to Xisco Faulí from comment #3) > Regression introduced by: > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=e6b200524bd5f614ab5ece88e8187466e7c40096 > Thanks Xisco. I suppose we should revisit optimizing this logic. It's going to be tricky, but probably worth spending some time to find a good workaround to avoid the cost of the Paragraph Signature RDF when not needed. I can't commit time at the moment, but will have it in mind.
Created attachment 145090 [details] Callgrind output from master Valgrind problem was solved by upgrading valgrind to the latest version. Somehow the package had not been updating with system updates (had to reinstall). Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 0ffa7a733d834647dfd59b864c52a015028822b6 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on September 21st 2018
the wery old libreoffice 5.3.7.2 is fast as lightening ! only the newer versions are DEAD slow.
it takes real 3m56,823s user 3m45,620s sys 0m0,898s in Version: 6.3.0.0.alpha0+ Build ID: e74de110d16c95414fac7541c8fe6541d4597113 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Noel, another one that might interest you
Perhaps it's been already better thanks to https://cgit.freedesktop.org/libreoffice/core/commit/?id=47e04cf31c6165dd55dc20962ad9c72962b958bd On pc Debian x86-64 with master sources updated today (Ryzen 2600 + 32GB), it launches after less than 30 secs
so nothing is done, the same slow things appears on EVERY SINGLE new releases. only the old 5.3 is working good. none of above.
(In reply to Hatlábú Farkas from comment #13) > so nothing is done, the same slow things appears on EVERY SINGLE new > releases. > only the old 5.3 is working good. > none of above. Please try an appimage of 6.3 or 6.4: https://libreoffice.soluzioniopen.com/
the brand new version 6.3.1.2 is STILL THE SAME SLOW as snail. i have use the old 5.3 again with all the small issues in there. but the speed is like the 3dfx.
Opens within 15 second Version: 7.1.0.0.alpha0+ (x64) Build ID: c48e4d795e37f23b71d647247590807ab9e52223 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
3 seconds for me. Let's close. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: 777f9cec0985f99451ecb804d5ae139a0be32253 CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 4 July 2020