Description: When a PPTX has a list with custom style exporting to ODP is 10 times slower. list.pptx use the default style. list-custom.pptx define a custom style with custom font and symbol. Info on how to define a custom list style in PowerPoint: https://support.microsoft.com/en-us/office/define-new-bullets-numbers-and-multilevel-lists-6c06ef65-27ad-4893-80c9-0b944cb81f5f#style Steps to Reproduce: I'm using this command on Ubuntu to convert the presentation to ODP and measure the time: time libreoffice --headless --convert-to odp list.pptx 1. convert list.pptx to odp from the command line and measure the time. 2. convert list-custom.pptx to odp from the command line and measure the time. 3. Compare the conversion time. Actual Results: Conversion time of list-custom.pptx is 10 time higher than list.pptx - 0.2 seconds and 2 seconds. Expected Results: Conversion time should be the same Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.3 / LibreOffice Community Build ID: 30(Build:3) CPU threads: 2; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-US (en_US); UI: en-US Ubuntu package version: 1:7.3.0~rc3-0ubuntu0.20.04.1~lo1 Calc: threaded
Created attachment 178140 [details] List with custom style
Created attachment 178141 [details] List with default style
IMHO, this is not an issue. Even if it's 10 times slower, you are comparing 0.2 seconds versus 2 seconds. Where is the issue there ? 2 seconds is more than acceptable
An order of magnitude difference for converting a single slide with a simple list is huge. I'm converting presentations with hundreds of slides that have lists with custom styles. When you multiply 2 seconds by 100 slides it adds up to minutes.
(In reply to Pablo from comment #4) > An order of magnitude difference for converting a single slide with a simple > list is huge. > I'm converting presentations with hundreds of slides that have lists with > custom styles. When you multiply 2 seconds by 100 slides it adds up to > minutes. Please, attach such a file then
Repro: when you have LibreOffice running on background, running these two commands > time libreoffice --convert-to odp list-custom.pptx > time libreoffice --convert-to odp list.pptx gives on my Ubuntu 20.4 ~4.9 s vs 0.39 s (using 7.3.0.3 from PPA).
Note: I can't see the difference in times when testing on Windows (with or without background instance). Without the background instance, the difference on Ubuntu is ~4.6 vs 8 s - so the difference here is similar in absolute numbers; startup/shutdown make it relatively less prominent.
(In reply to Xisco Faulí from comment #5) > (In reply to Pablo from comment #4) > > An order of magnitude difference for converting a single slide with a simple > > list is huge. > > I'm converting presentations with hundreds of slides that have lists with > > custom styles. When you multiply 2 seconds by 100 slides it adds up to > > minutes. > > Please, attach such a file then Jut to be clear, the reason why I'm asking for the file is to check whether the affirmations "When you multiply 2 seconds by 100 slides it adds up to minutes" and "10 times slower" are true or not with larger files. Besides, when working on a performance issue, it's easier to see the improvements when the differences are longer than just a few seconds. So, if you have some time, could you please create the file and attach it ? Thanks in advance
Created attachment 178523 [details] List with default style (100 slides)
Created attachment 178524 [details] List with custom style (100 slides)
Tested on Ubuntu 20.04 running LibreOffice 7.3.0.3 time libreoffice --headless --convert-to odp list-100.pptx 2.712s time libreoffice --headless --convert-to odp list-custom-100.pptx 14.603s
@Julien, any chance you could get a perf graph here ?
it takes real 0m15,736s user 0m15,404s sys 0m0,224s in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 0723b41bed9bb4ad50d2993744a60177966d1a21 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded and Version: 6.4.0.0.alpha1+ Build ID: 9bc848cf0d301aa57eabcffa101a1cf87bad6470 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3; Locale: es-ES (es_ES.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 178537 [details] Flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today (02caa6e40cfa55d96befc82515b343045b5cfd7b) + gen rendering. (file used: list-custom-100.pptx)
(In reply to Julien Nabet from comment #14) Thank you! The flamegraph shows clearly why this is Linux-specific. It spends a huge amount of time in fontconfig called from psp::PrintFontManager::Substitute; so it looks like missing font issue, caching issue, and maybe fontconfig performance issue at the same time. But I'm just speculating :) Caolan: maybe you have an idea how to deal with this?
(In reply to Mike Kaganski from comment #15) > (In reply to Julien Nabet from comment #14) > > Thank you! > The flamegraph shows clearly why this is Linux-specific. It spends a huge > amount of time in fontconfig called from psp::PrintFontManager::Substitute; > so it looks like missing font issue, caching issue, and maybe fontconfig > performance issue at the same time. But I'm just speculating :)... No pb! Retrieving a Flamegraph is quite easy and requires not much time so don't hesitate to ask if it can help Of course, it's useless to systematically retrieve a Flamegraph for all perf bugs if nobody gives it a look in the following days/weeks since the code may have changed more or less in the meantime. But knowing Caolán's reactivity, I suppose there'll be no pb for this one! :-)
It is possible this is the same type of problem as bug 137571 and relating also to bug 123470 If the problem exists in trunk right now it is possible that deploying the same fix of an ActionGuard in the right place (as used for bug 137571) could be useful.
I amend the title with "on 1sr run" because only 1st run is slow, 2nd run of the same command is fast. Applies both to 7.3-oldest and 7.4-master. (Seems that 1st run was becoming more slow with newer LO, from 8 to 34 secs for me. But I didn't check what's exported).
I amend the title with "on 1sr run" because only 1st run is slow, 2nd run of the same command is fast. Applies both to 7.3-oldest and 7.4-master, both for default attachment 178523 [details] and custom attachment 178524 [details]. So title seems wrong from the beginning (did you run custom first and then default without clearing from the memory or reboot?). (Seems that 1st run was becoming more slow with newer LO, from 8 to 34 secs for me. But I didn't check what's exported).
I think we can ignore comment #17 as twaddle. Looking at it a little more, the glyph fallback is from "Noto Sans Symbols" for codepoint 0x25aa. That font doesn't have this bullet, fontconfig suggests that we could replace it with "Noto Color Emoji" *but* additionally suggests we apply an extra matrix to skew it. Back in bug #32665 we disabled the cache for "emboldened" and this sort of "fake italic" glyph fallback suggestions.
Created attachment 178619 [details] reproduce for the original problem Checking my local FreeSerif, if the cache is enabled again for this case then this example will render missing glyphs if the range is made italic in additional to the current bold.
I'll take this because I've some work done looking into it. Fundamentally the font used for the bullet doesn't appear to have the selected symbol in it and this is a glyph fallback case so it might not be a mainstream problem. What font is used for the glyph fallback may differ from system to system depending on what's available for use so we might be seeing different results. Anyway, the commits I'll push bring it from from 8 seconds to 3 seconds to convert this on the command line for my setup. https://gerrit.libreoffice.org/c/core/+/130892 https://gerrit.libreoffice.org/c/core/+/130877
Is it possible to reset LO state after 1st run, so that 2nd run is fresh like after reboot?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8716721f4645078b04770271c71f7687a2b21e07 Related: tdf#147283 set a concrete weight for the bullet font 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/04f9a8957c04b8c5abaa58140328d2c83381f4ff tdf#147283 allow 'fake italic/bold' glyph fallback results to be cached 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.
(In reply to Timur from comment #23) > Is it possible to reset LO state after 1st run, so that 2nd run is fresh > like after reboot? "Not really" is probably the answer there because it tends to be the operating system (and hardware) caches and I never had any great success with the various Linux cache dropping techniques to get reliable consistent results (assuming that is it those caches in operation)
Thank you for the fix. I'll test it as soon as it's available in the daily build. It will be great if it's possible to include the fix also in the 7.3.x branch?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/ea7f625a83d9d9772c2bea2d52e0ed5f8622b6b6 tdf#147283 allow 'fake italic/bold' glyph fallback results to be cached It will be available in 7.3.4. 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.