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.
It took 10 sec in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1516711eb7861a08cc9fd19ec867360737a6d070 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded 4 core CPU Intel Core i5 2,5GHz + SSD I closed it as WFM Timur, please retest and reopen it if you still have more time for opening
Let's rather close as fixed as there are many commits in this
Roman, I think you should not close bugs with testing only LO master. You need to compare master with pre-bibisect version, but for those perf bugs also with Microsoft. Buovjaga, also: I don't have SSD but 7.3+ took 46 sec where OO took 15 sec and MSO took less than 4 seconds, all 1st time run. So this should only be closed if some further action is explained.
(In reply to Timur from comment #32) > Roman, I think you should not close bugs with testing only LO master. > You need to compare master with pre-bibisect version, but for those perf > bugs also with Microsoft. > > Buovjaga, also: I don't have SSD but 7.3+ took 46 sec where OO took 15 sec > and MSO took less than 4 seconds, all 1st time run. > So this should only be closed if some further action is explained. What CPU do you have?
(In reply to Buovjaga from comment #31) > Let's rather close as fixed as there are many commits in this +1 With the addition of opening a new ticket regarding comment 26 comment 32 It's still 25 seconds or so on my system only utilizing 15% of a 4 core CPU (expected 25%). It also opens with a change registered
(In reply to Roman Kuznetsov from comment #33) > What CPU do you have? Intel Core Sandy Bridge-DT i7-2600 @ 3.40Ghz. Same CPU with MSO that opens it fast. Interesting that it's real slow in Windows, but acceptable in Linux.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/240a345bc3891887ed551e780ce619d8da303325 tdf#121740 reduce cost of OStorage_Impl::GetElementNames It will be available in 7.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/1fe08ae6b383c2222178a21c926480a055a87f99 tdf#121740 increase DrawingEngine::OLE_Objects cache limit It will be available in 7.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/a5af08b3ed160a569d389474dc5d5445dccf3a63 tdf#121740 fast path in cancelCommandExecution It will be available in 7.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/9a1f81f2e0fbc0306cfa6317b41fe2c0bf04fe4c tdf#121740 reduce cost of SfxDocumentMetaData::Init It will be available in 7.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/3c25a2a114c0bb66641ad27499610fe5ee4393b9 tdf#121740 dont bother checking for VBA libraries It will be available in 7.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/2d63a011ed161a01419a40ab2fbb88796d59b20a tdf#121740 just remove OLE_Objects limit for non-32-bit-Windows It will be available in 7.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/f7f527a0add582cde2f34d992b65ed6ec79633d4 tdf#121740 std::set->o3tl::sorted_vector in ImpEditEngine::FormatDoc It will be available in 7.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/301b5c0aea7a525c436b0f2f54a8cef8be947c89 tdf#121740 avoid some temporary OUString construction It will be available in 7.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/8ad920befe1290c40ef762e8d7d9797b1924f5d2 tdf#121740 reduce cost of mathml parsing It will be available in 7.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/d01f8813084b245492c83cf750bb59bcd2659621 tdf#121740 cheaper to clear namespacemap rather than allocating It will be available in 7.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/22e08a3d8b043ce0ff2424d3fa0a704804afc567 tdf#121740 cache hashcode in SequenceAsHashMap It will be available in 7.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/e6cca743556c2135d5e381cdbd883e937221eef9 tdf#121740 elide temporary CacheItem object in BaseContainer::getByName It will be available in 7.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.
Works fine for me, running Windows 10. Test times on the file from attachment 147067 [details]: 22 seconds with LO 3.6.7.2 18 seconds with LO 5.4.7.2 12 seconds with LO 7.3.7.2 8 seconds with LO 7.4.3.2 while for comparison PowerPoint 365 took 11 seconds to open the file. To make sure that it was not a question of caching, the file was in all cases opened twice, with the time from the second opening (where the system would have things in cache). Thus, the file now opens considerably faster than in earlier versions, and faster than in PowerPoint.
Worksforme is the wrong status here as we have commits toward this.