Created attachment 137113 [details] A file from https://www.boredpanda.com/73-year-old-excel-paintings-tatsuo-horiuchi/ The file opens and shows its contents (huge line art), but UI is unresponsive. As FLHerne at #libreoffice pointed out, "a fun stress test". Tested with Version: 5.4.2.2 (x64) Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Windows 6.19; UI render: default; Locale: ru-RU (ru_RU); Calc: CL
Confirmed in Version: 6.0.0.0.alpha1+ Build ID: 118a0a3734a3f794c67a9d7d4376d8ed78a96fee CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Actually, it's responsive, but it needs some time ;-)
Also reproduced in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Reproduced for me with Version: 5.4.2.2.0+ Build ID: 5.4.2-2 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group It does eventually become responsive, but becomes immediately unresponsive when trying to scroll.
** 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
There is some improvement in 6.2. The UI becomes unresponsive for about 15s after each interaction with the document; in LO 5.4 this took almost two minutes. Version: 6.2.0.3 Build ID: 6.2.0-3 CPU threads: 4; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
Created attachment 150912 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
Noel: noticing your optimization on Calc, thought you might be interested in this one. Of course, don't hesitate to uncc yourself if no time or focus only on conditional formatting part.
it takes real 3m22,013s user 2m32,302s sys 0m1,874s to open in Version: 6.3.0.0.alpha0+ Build ID: e913727c7ee3af0bb4031c6829abfb3373306492 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
Created attachment 150927 [details] perf flamegraph
BTW, I waited several minutes but it didn't finish so I had to stop it.
Also I noticed a lot of these on console: warn:svl.items:25499:25499:svl/source/inc/poolio.hxx:68: make this item sortable to speed up managing this set warn:sc:25499:25499:sc/source/filter/excel/xlstyle.cxx:159: XclDefaultPalette::GetDefColor - unknown default color index: 193 (there were also other numbers too: 16384, 8193, 459, 387...)
Julien, are you generating a flame graph from a debug build - because that will produce misleading results....
(In reply to Noel Grandin from comment #13) > Julien, are you generating a flame graph from a debug build - because that > will produce misleading results.... Yes, I use a debug build. So I should stop using Flamegraph?
(In reply to Julien Nabet from comment #14) > > Yes, I use a debug build. So I should stop using Flamegraph? No, just use a --enable-symbols build when you need to do performance analysis :-)
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/10c934147d469965dba6abc78efd02759a010b8e%5E%21 tdf#113266 slow opening XLS with 45 MB drawing 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.
Noel, is this bug fixed? Or will be else 5-6 parts of fixing? =)
I won't be working on this bug anymore, I have no opinion over whether it is fixed or not, my change would only have shaved a few % off the rendering time
(In reply to Xisco Faulí from comment #9) > it takes > > real 3m22,013s > user 2m32,302s > sys 0m1,874s > > to open in > > Version: 6.3.0.0.alpha0+ > Build ID: e913727c7ee3af0bb4031c6829abfb3373306492 > 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 1m20,541s user 1m19,989s sys 0m0,520s in Version: 6.3.0.0.alpha0+ Build ID: 0a04150b6eefb5feb7ecefaa5cd63dbac8c1574f 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 quite a nice improvement... My take: RESOLVED FIXED. Up to Mike Kaganski as he's the reporter...
it would be nice if other could measure it before and after...
(In reply to Xisco Faulí from comment #19) > quite a nice improvement... My take: RESOLVED FIXED. Up to Mike Kaganski as > he's the reporter... It opens in 1:18 for me. In Excel 2013 it opens in 10s. UI is still very unresponsive in Calc, I'd go as far to say that it hangs. Excel isn't very responsive when clicking the image, but only takes ~10s, otherwise it's quite responsive.
(In reply to Aron Budea from comment #21) > It opens in 1:18 for me. I was checking with a 32-bit Windows daily build from today (2019-04-24, 951282a27a9dd4c64fc206fcbdd805b4cb602816).
In my case, MSO opens in 58 seconds and LO in 64 seconds. So opening time is OK. But LO is not responsive after opening. Is it another issue, related to image handling like Bug 47148 or specific to this drawing type image?
I've just rechecked with the same commit I mentioned in commit 19 and this time I've got: real 1m46,080s user 1m24,239s sys 0m1,146s while in Version: 6.3.0.0.alpha0+ Build ID: 3ab6d246cc44617af5ed416b5d49f2f35b61ceea 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 1m8,876s user 0m47,064s sys 0m1,210s @Timur, @Aron, could you please check again on your end ?
Similar to Aron, I tested with Windows build. master~2019-04-24_00.11.09_LibreOfficeDev_6.3.0.0.alpha0_Win_x86.msi. Today I had machine loaded and opening takes 100 seconds in LO and 130 secs in MSO. With libo-master64~2019-03-26_23.06.31_LibreOfficeDev_6.3.0.0.alpha0_Win_x64.msi it's 120 seconds. Not sure how much the fix improved loading time, seems some. My point was that LO is faster to open than MSO and it's hard to expect more.
On macOS10.14 Excel 16.16.9 (190412) : 35s LO6222 : 1m52s Tested with Version: 6.3.0.0.alpha0+ : 45s Build ID: dfae42730911256dceb8369528ee9d9944a0fa3e CPU threads: 8; OS: Mac OS X 10.14.3; UI render: GL; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Alex Thurgood from comment #26) > On macOS10.14 > > Excel 16.16.9 (190412) : 35s > > LO6222 : 1m52s > > Tested with Version: 6.3.0.0.alpha0+ : 45s > > Build ID: dfae42730911256dceb8369528ee9d9944a0fa3e > CPU threads: 8; OS: Mac OS X 10.14.3; UI render: GL; VCL: osx; > Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US > Calc: threaded That commit doesn't exists -> https://cgit.freedesktop.org/libreoffice/core/commit/?id=dfae42730911256dceb8369528ee9d9944a0fa3e
The main problem with the file was, as described in the initial description, "The file opens and shows its contents (huge line art), but UI is unresponsive". Also, the bug title was "LO (UI) hangs on opening specific (XLS) document" on creation. That seems like a funny shift of focus, when later rename made the focus be on opening time ;-) It's really nice to see the improvement of load time, but ... the original problem needs addressing, too :-)
(In reply to Xisco Faulí from comment #24) > @Timur, @Aron, could you please check again on your end ? In 6.3.0.0.alpha0+ (8f03bdee8225c619305ef210391dcc3b6c6fe284) (x86) / Windows 7, it takes ~52s with default rendering, and ~60s with OpenGL rendering. Unfortunately, as I wrote it quite often hangs completely afterwards, when just leaving LO there, not doing anything.
I noticed this log in a never ending loop: warn:legacy.osl:4916:8100:basegfx/source/polygon/b2dtrapezoid.cxx:650: Trapezoid decomposer in illegal state (!)
Taking a look at basegfx/source/polygon/b2dtrapezoid.cxx, I noticed this comment twice "consume both edges" (lines 714 and 872) but saw this: maTrDeEdgeEntries.pop_front(); maTrDeEdgeEntries.pop_front(); whereas I would have expected: maTrDeEdgeEntries.pop_front(); maTrDeEdgeEntries.pop_back();
(In reply to Julien Nabet from comment #31) > Taking a look at basegfx/source/polygon/b2dtrapezoid.cxx, I noticed this > comment twice "consume both edges" (lines 714 and 872) but saw this: > maTrDeEdgeEntries.pop_front(); > maTrDeEdgeEntries.pop_front(); > > whereas I would have expected: > maTrDeEdgeEntries.pop_front(); > maTrDeEdgeEntries.pop_back(); No problem there; the code checks if (bSameStartPoint && bSameEndPoint); the two are comparison of aLeft and aRight; and the latter two are taken from iterating maTrDeEdgeEntries twice from the beginning.
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://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
Perf regressed meanwhile: bug 161875
(In reply to Buovjaga from comment #34) > Perf regressed meanwhile: bug 161875 Now the opening perf regression was fixed and I can confirm the UI is still sluggish after opening. Opening time itself is acceptable, 11 secs for me. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7628892b04d1a1ed47d6d6c355940f9915dcd99 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded