Description: Applying bold formatting to a large dataset is slower as it has been before Steps to Reproduce: 1. Open the attached file. 2. Select all data existing between A:1 and O:245814 3. Press CTRL+B of click BOLD in the formatting menu Actual Results: With recent versions it takes around 40 seconds (or more) to apply Expected Results: In Libo 4.1.0.4 it takes a few seconds. Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 5.5.0.0.alpha0+ Build ID: ec79f3453471ee9b6ae32e71ff16ea99d9b7751c CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-05-28_23:21:44 Locale: nl-NL (nl_NL); Calc: CL and in Version: 4.3.7.2 Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba but not in Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 133798 [details] Example file
in Version: 5.5.0.0.alpha0+ Build ID: 9956849c2ea6049582e2ccf04c355542c1ef00a1 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and in Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 it takes approximately 55 seconds while in Version: 4.1.0.0.alpha1+ Build ID: a2c9d4f8bbde97f175bae4df771273a61251f40 it takes 1 second it needs to be bisected with repo bibisect-42max
Working on debian-stretch in the bibisect-42max repository, I see that the slowness entered LO somewhere in the 43 commits to master ... commit s-h -------- -------- good 690230ca ac84ffb3 bad 8e7bade4 4c99a427 This is the same range in which bug 106646 entered LO. I am not deeming these to be duplicate bugs, but a fix to either is obviously reason to retest the other. I am removing keyword bibisectRequest and adding bibisected.
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ac84ffb3c90bb5788608eadf2177f587021daaad..4c99a427ee4adaeddb2682c192384bad21d9d09b
** Please read this message in its entirety before responding ** 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
hm, I created new spreadsheet with random numbers in range A1:O255000, selected all cells and pushed Ctrl+B. All numbers became have bold fonts ... momentally! For file from attach it takes about 10 sec (why?!) @Xisco: WFM or not?
Using the attached document, it has improved since the last time I tested it. in Version: 6.2.0.0.alpha0+ Build ID: 2419fa71d8b2223a50f596d5db7721f6213d4f87 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded now it takes 14 seconds with or without threading enabled... However, it takes 2 seconds in LibreOffice 4.1, so let's keep it open for the time being...
Created attachment 150737 [details] Perf flamegraph Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 9030ffb1a1b282eb2c6d1773930b0de0d42df447 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 13 April 2019
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/4c4c5baaf017b2861daf039de179eaa7303b13b0%5E%21 cache mdds position in ScTable::InvalidateTextWidth (tdf#108298) It will be available in 6.3.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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/390bd27d92971d9f523b20510554334e30ae9b9d%5E%21 cache mdds position in ScAttrArray::RemoveCellCharAttribs() (tdf#108298) It will be available in 6.3.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.
Verified with stopwatch: ~1 second now! (Explicitly giving the range A1:O245814 Arch Linux 64-bit Version: 6.3.0.0.alpha1+ Build ID: 7aa30433719faece8c40e41d7aa8c7539287932d CPU threads: 8; OS: Linux 5.1; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 19 May 2019