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.

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.

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.

(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 (!)

(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