Description: FILEOPEN DOCX: Memory usage exploding (images in table) Steps to Reproduce: 1. Open the attached file 2. Save as DOCX 3. File reload Actual Results: Loading slow; surely needed 3 GB Expected Results: Not so Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 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 and in 6.4 (after scrolling the second which actually contain the images) opening pretty fast (except most of the images show up as empty frames) Version: 6.3.0.0.beta1+ (x86) Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL and in Version: 6.2.0.0.alpha0+ Build ID: 2bc84658cce1df5050fe788dd0c8a0906a1ca2c3 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL Not in (file opening is however boringly slow) 6.0.5
Older versions tend to behave similar.. Also seen in 3.5.0.3
@Justin Any clue whats going wrong here; or a person who might now.. Can't decide between Miklos, Tomaz, or even Armin. As it's about images loading at docx import.
Armin never responds to anything. I've Tomaz speaking intelligently about image stuff. There is no attached or mentioned file here. You should also bibisect when it switches from fast/missing images to slow/displayed images.
Created attachment 164855 [details] Example file
Created attachment 164856 [details] Reduced Example file
Created attachment 164857 [details] Reduced Example file
@Buovjaga You're system slightly better equipped (powerful/more ram). I'm going OOM with DOCX export of the Reduced example (I need to kill the process before my system freezes) with 7.1. Older versions are working' of empty image frames & slow loading.
(In reply to Telesto from comment #7) > @Buovjaga > You're system slightly better equipped (powerful/more ram). I'm going OOM > with DOCX export of the Reduced example (I need to kill the process before > my system freezes) with 7.1. Older versions are working' of empty image > frames & slow loading.
(In reply to Telesto from comment #7) > @Buovjaga > You're system slightly better equipped (powerful/more ram). I'm going OOM > with DOCX export of the Reduced example (I need to kill the process before > my system freezes) with 7.1. Older versions are working' of empty image > frames & slow loading. The export itself is fine, but after reloading mem use peaks at 13,8GB. The good peaking is only 3,7GB. Bibisected with linux-64-7.0 repo. In the bibisect, I considered as bad also the increase to 6,8GB. I only kept opening the same DOCX, I did not re-export it during the bibisect. https://git.libreoffice.org/core/commit/828504974d70111e4a35b31d579cf42fe660a660 tdf#130768 speedup huge pixel graphics Cairo Adding Cc: to Armin Le Grand
(In reply to Buovjaga from comment #9) Thanks for the bibisect. They 3,7 GB will still freeze my system, I guess. Few questions 1) Only for my impression: which file did you use? 12 GB with the reduced file or the original? 2) Which backend did you use. X11, GTK3 & does the opening go smooth? It's pretty bad on Windows back to 3.5.0. Read-errors for images etc. Constant CPU hammering (after file open)
(In reply to Telesto from comment #10) > (In reply to Buovjaga from comment #9) > Thanks for the bibisect. They 3,7 GB will still freeze my system, I guess. > > Few questions > 1) Only for my impression: which file did you use? 12 GB with the reduced > file or the original? Reduced. > 2) Which backend did you use. X11, GTK3 & does the opening go smooth? It's > pretty bad on Windows back to 3.5.0. Read-errors for images etc. Constant > CPU hammering (after file open) Now I tried with gen backend and surprisingly the explosion to 13,8GB was not visible. So only with gtk3 and kf5. By opening I assume you mean opening the .odt file. It certainly is a lot smoother than the .docx. Mem use never rises above 800MB with non-gen. With gen, the opening is actually instant!
Fixed by https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11. Closing as a duplicate of bug 138068 *** This bug has been marked as a duplicate of bug 138068 ***