Created attachment 147067 [details] Original PPT PPT from Bug 109340 with Equation 3.0 objects opens slow in LO. Tested in Windows. File opens without dump. Same PPT resaved in MSO also opens similarly slow so I find it worth reporting. Note: PPTX saved in MSO opens faster. First fileopen time for me in Windows: 75 seconds LO 6.3+, tested both with x86 and x64. 100 seconds with LO 5.4. 60 seconds with LO 5.2. 40 seconds with LO 4.0. 15 seconds with OO. MSO takes 8 seconds. Note: 18 seconds for PPTX saved by MSO.
Bug not reproducible in version : 6.3.0.0.alpha0+ (x64) I used the ppt you attached as the test file and the problem you descripted didn't occur. 我載入的挺快的 the ppt is loaded fast like lightning.
ADDITIONAL REMARKS ABOUT MY VERSION: 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
My reported slow loading is in Windows 7. OpenGL disabled. I also tested in Mint VM and it's 15 seconds.
I can confirm that the bug is present in Version: 6.0.6.2 Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group It takes about 80 seconds to load
Win only. In Version: 6.3.0.0.alpha0+ Build ID: 1ee8d4f63adf3113a4733a479c8faf9eb65f7b8d 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 it takes real 0m9.877s user 0m8.521s sys 0m0.599s
Similar timing in Versión: 6.1.3.2 Id. de compilación: 86daf60bf00efa86ad547e59e09d6bb77c699acb Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded thus, I can't reproduce it on win either. Only x64 ?
(In reply to Xisco Faulí from comment #6) > Similar timing in > > Versión: 6.1.3.2 > Id. de compilación: 86daf60bf00efa86ad547e59e09d6bb77c699acb > Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; > Configuración regional: es-ES (es_ES); Calc: group threaded > > thus, I can't reproduce it on win either. Only x64 ? Timur said both with x86 and x64. Timur: please, can you test again with a recent master build? I cannot repro the slowness. Version: 6.3.0.0.alpha0+ (x64) Build ID: 13279b94080d87dde51bc8b8c669212bf71cacca CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-23_04:38:36 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
With current master, this takes less than 10s to load for me
(In reply to Noel Grandin from comment #8) > With current master, this takes less than 10s to load for me @Noel, did you test it on Linux or Windows ? This is only reproducible on win
My apologies, I only tested this on Linux. I'll see if I can get my windows build working again.
With current master(basically 6.3) this takes 20s to load on my Windows box, which seems reasonable to me
(In reply to Noel Grandin from comment #12) > With current master(basically 6.3) this takes 20s to load on my Windows box, > which seems reasonable to me Depending on the comparison I guess. It's rather slow compared to Powerpoint.. But pretty OK for LibO
Maybe Telesto wants to make a flame graph and we can see where the time goes?
(In reply to Noel Grandin from comment #14) > Maybe Telesto wants to make a flame graph and we can see where the time goes? I would love too.. but last time I tried I got lot of PDB mismatched for some unknown reason (so I get something like this: attachment 151678 [details] [unrelated]). Not specific to the flamegraph script BTW, also happening with WPA (Windows Performance Analyzer)
(In reply to Buovjaga from comment #7) > Timur: please, can you test again with a recent master build? I cannot repro > the slowness. 75 seconds for current LO 6.4+
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f2c3ea4f54d634ab54702d6fe07ccd4d4d76bdc1%5E%21 tdf#121740 improve ppt load time on windows, reduce image swapout It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/875f65ad5240b891ed1e5b3e17946816a4afe98a%5E%21 tdf#121740 improve ppt load time on windows, reduce image swapout It will be available in 6.3.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have slow HDD (no time or will to change to SDD) so loading time is now 65 secs for the first time. Next time it's 55 secs.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/37e3573bb5739c94890c18ed11b4f4cc8a4df67f tdf#121740 speed up font loading It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90ea305110e5881256ba272800074a2a9f6b613d tdf#121740 cache font data to speed up PPT load It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/29d2024e16ce3cb81ad7f5b5f7e1b93378a93199 tdf#121740 cache font data to speed up PPT load It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On another Window system, I open in 30s in LO6.5+, as in LO6.2 and LO5.4, 20s in OO3.3. MSO takes 8 seconds. I don't have my previous system now to compare.
(In reply to Timur from comment #23) > On another Window system, I open in 30s in LO6.5+, as in LO6.2 and LO5.4, > 20s in OO3.3. MSO takes 8 seconds. > I don't have my previous system now to compare. so, according to your tests, there's no performance improvement after this committ...
Linux has a nice time command but Windows seems to have only workarounds (using power-shell or manual time or timemem utility). Here, 1st open is slower and 2nd open faster, so I measure 2nd open. Can't say why numbers are different from previous, maybe because this time I launch complete suite from the command line, so it's not just the file measured manually. I open in 84s in LO7.0+ (with page fault #: 1000, Working set: 4 MB, Page file size: 1 MB), 100s in LO6.2, 175s in LO5.4, 80s in LO3.3, 25s in OO3.3. MSO takes 8 seconds (with page fault #: 42000, Working set: 100 MB, Page file size: 55 MB). Now, it seems to me (doesn't have to be true) that LO was never faster, as current speed is as in LO3.3, but OO was. Does MSO load time and memory use has something with multi-processing? I'm not sure if flamegraph would help, let's hope so.
Our load process for PPT is particularly convoluted, we load PPT into an intermediary format, write that intermediary format out to temporary file on disk, then load the intermediary format. So short of a full rewrite of that import process, we can't get close to Microsoft speeds. That said, there are still a number of places that can be made faster, if anyone wants to look. I recommend using the community version of Intel VTune Profiler, it has a very good UI.
Created attachment 159389 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
(In reply to Noel Grandin from comment #26) > Our load process for PPT is particularly convoluted, we load PPT into an > intermediary format, write that intermediary format out to temporary file on > disk, then load the intermediary format. > > So short of a full rewrite of that import process, we can't get close to > Microsoft speeds. Thanks for clarification. Is it only PPT? Would that be a justified proposal for https://wiki.documentfoundation.org/Development/Budget2020?
(In reply to Timur from comment #28) > (In reply to Noel Grandin from comment #26) > Thanks for clarification. Is it only PPT? No idea. > Would that be a justified proposal for > https://wiki.documentfoundation.org/Development/Budget2020? Ditto.
