Created attachment 145503 [details] A test ODS with 2 macros to test Formula vs FormulaLocal performance In the attached file, the two macros (testformulalocal and testformula) only differ in using FormulaLocal vs Formula. The performance of the latter is an order of magnitude slower than that of the former (testformulalocal executes in about 90 s on my system, while testformula takes ~1400 s).
It is necessary to run the testformulalocal macro with "Use English function names" enabled when using a non-English UI.
Repro the same proportion of time. Do you want a callgrind trace? Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 9a373521d7a328197a4bf9abeb0a981b7acba896 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 19 October 2018
Dear Mike Kaganski, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Mike Kaganski, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
FormulaLocal parses every given text (formula) in the users native UI language in bool ScDocFunc::SetCellText and this process needs time, since it will be done every time. Could we extend ScInputStringType ScStringUtil::parseInputString to get the correct local format to avoid scanning it over and over again? Or we could avoid the parsing of the inputr string if it is a formula?
(In reply to Andreas Heinisch from comment #5) > FormulaLocal parses every given text (formula) in the users native UI > language in bool ScDocFunc::SetCellText and this process needs time, since > it will be done every time. Just to make sure we are on the same page: this issue is about *Formula* property being much slower than FormulaLocal, not the other way round.
from 5 to 1500: without the patch FormulaLocal: 107s Formula: 15s with the patch: FormulaLocal: 17s Formula: 16s The first run always takes a little bit longer on both Formula/FormulaLocal calls.
Likely, something has changed since then: *both* testformula started to work much faster, *and* testformulalocal started to work much slower. And also it seems that I wasn't clear enough in STR. Let me explain. To check, I opened the file in 6.2.0.3, and made changes according to comment 1 (I use Russian UI, and Use English function names). Version: 6.2.0.3 (x64) Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: ru-RU Calc: CL First I run testformulalocal (the first in the module). It took less than 10s on my system. Then I run testformula, and it took very long. Just as I explained in the report. Now I decided to double-check running testformulalocal again, and this time, testformulalocal took longer than 90 s. Not nearly as log as testformula, but it made it clear that the repro steps should had a step like "run testformulalocal once before further testing" to get the numbers reported back then. However, testformula worked very slowly even with clear column L. So in the end: the report was valid for version 6.2. But let me clarify the problematic numbers from comment 0 using v.6.2: testformulalocal took ~7s the first time on clean column L, and ~100s when run the second time on already filled column L. testformula took ~860s the first time on clean column L, and ~1400s when run the second time on already filled column L. Now I re-test using 7.3.5.1 (again, Russian UI, and Use English function names). Version: 7.3.5.1 (x64) / LibreOffice Community Build ID: d56c1c78db15939340c3db8ee3b6667832313d23 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL testformulalocal took ~13s first time (with clear column L). Re-running it again, with already filled column L, takes now ~650s. A regression in the second case. testformula took ~11s first time (with clear column L). Re-running it again, with already filled column L, takes now ~24s - great improvement over v.6.2 in both cases. I close this one as WORKSFORME (because Formula now works at least no longer than FormulaLocal now, and much better than in 6.2, and also faster than FormulaLocal took back then in the worst case). But the regression in FormulaLocal needs a separate issue, bisection and fixing. Andreas: I assume, this is what you do in https://gerrit.libreoffice.org/c/core/+/136942 - but I still see different figures compared to comment 7, so there's some additional aspect here that I don't see.
My observations on: 5 to 15000 FormulaLocal 18s not filled 634s filled Formula 314s not filled 35s filled Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
(In reply to Andreas Heinisch from comment #9) > Formula > 314s not filled > 35s filled Sorry to re-check: is 314 correct, or maybe it was a typo, and was meant e.g. 14?
Was no typo: 314s was correct.
(In reply to Andreas Heinisch from comment #11) Thank you for clarifying! This zoo of different timings is highly confusing; the 314 makes your timings differ from mine :-)
I think this is something different here, because I note that the formulas are already set in the UI, and the UI does not respond nor the macro ends in with the patch: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 8e19c9defc0f7ca6e8eabc36261336743f946276 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL