Created attachment 139460 [details]
Screencast

System: Ubuntu 16.04.3, 16GB RAM, i7 CPU, SSD

How did you install both v5.4 and v6.0? Is the 5.4 one from Ubuntu repo/ppa, and v6 from TDF DEB? then the comparison is senseless, because the former is built with optimizations absent in TDF releases.

it take's 3.4 seconds to open the file, so no repro

Version: 6.0.1.0.0+
Build ID: 26dc825d9fe7fe6a4188fc6ef68bc801fc8db064
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

I installed 6.0.0.2 and 6.0.0.3 from https://wiki.documentfoundation.org/QA/GetInvolved#Test_Pre-releases (http://dev-builds.libreoffice.org/pre-releases/deb/x86_64/LibreOffice_6.0.0.3_Linux_x86-64_deb.tar.gz, more specifically)
and 5.4.4.2 from https://www.libreoffice.org/download/download/ (more specifically, http://mirror.sjc02.svwh.net/tdf/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz)

Then I installed 6.0.0.3 from https://ftp.gwdg.de/pub/tdf/libreoffice/stable/6.0.0/deb/x86_64/LibreOffice_6.0.0_Linux_x86-64_deb.tar.gz and it's just as slow as the dev build.

I haven't ever installed LO from an Ubuntu repo or PPA. I've always downloaded the x86_64 .debs from libreoffice.org/download and ran `sudo dpkg -i *.deb`.

As a friendly note, testers with a thinner skin might be rubbed the wrong way by abrupt statements like "the comparison is senseless", when they've taken the time to submit screencasts showing a clear difference in speed. Also, they might not know what "TDF DEB" is (I imagine those are .deb files provided by The Document foundation?).

I have a thicker skin, fortunately, so I'll ask instead where exactly I should download v6 from, and how come my v5 is still faster, even though it comes from a URL that contains both "tdf" and "deb" in it. Does that mean that if I installed LO from some Ubuntu PPA, it would be even faster? Why isn't there anything about this difference in speed mentioned on the libreoffice.org/download page?

(In reply to Dan Dascalescu from comment #4)
> As a friendly note, testers with a thinner skin might be rubbed the wrong
> way by abrupt statements like "the comparison is senseless", when they've
> taken the time to submit screencasts showing a clear difference in speed.

Then they would do outright wrong, because "senseless comparison", connected with specific conditions when it is, relates to comparison, and not to efforts. I cannot help if people feel offended when they wrongly attribute something personally, and don't think that I should re-phrase logically consistent sentences in anticipation of such an event (or else I better don't try to answer at all). The question aimed to clarify one detail that might have something to do with the reason of your observations, and described why it is relevant.

> Also, they might not know what "TDF DEB" is (I imagine those are .deb files
> provided by The Document foundation?).

Yes.

> I have a thicker skin, fortunately, so I'll ask instead where exactly I
> should download v6 from, and how come my v5 is still faster, even though it
> comes from a URL that contains both "tdf" and "deb" in it. Does that mean
> that if I installed LO from some Ubuntu PPA, it would be even faster? Why
> isn't there anything about this difference in speed mentioned on the
> libreoffice.org/download page?

Because the Ubuntu packaging team is not TDF, and whatever they do with their packages, is not something TDF keeps track of. Of course, any distro has an advantage to be able to build their packages against system libraries, while TDF generates builds that are expected to run on widest possible systems, so have very old baseline etc.

To make absolutely sure I'm using the TDF build for v5, I've run `apt remove libreoffice5.4; apt autoremove`, then downloaded http://mirror.clarkson.edu/tdf/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz and installed it.

I'm still seeing the same speed difference from the original screencast.

Does my comparison make sense now? What extra debugging information can I provide to help track this issue?

(In reply to Dan Dascalescu from comment #6)
> Does my comparison make sense now?

Absolutely.

> What extra debugging information can I
> provide to help track this issue?

Well, now it's others' turn - to reproduce and confirm (I assume).

(In reply to Dan Dascalescu from comment #6)
> What extra debugging information can I
> provide to help track this issue?

Ah, one other thing I forgot to ask. Could you try opening the file in those versions from console, and look at the console output - if there's something different there? If so, then please provide the outputs as textual attachments.

Both `libreoffice6.0 food-bug.ods` and `libreoffice5.4 food-bug.ods` commands output the same "javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx"

No repro on Win 10, LibO 5.3.0 alpha1 vs. 6.0.1.

I could bisect it with 'time OOO_EXIT_POST_STARTUP=1' and this is what I found:

Before commit 1bb07b763560b7af64da27025b8f6299308b62a6 it takes

real	0m2.880s
user	0m2.453s
sys	0m0.274s

and after

real	0m4.518s
user	0m2.484s
sys	0m0.244s

which is a difference of 1,6318 seconds....

IMHO, 1.6 seconds it's an acceptable delay. It's not worth it to expend time and man power to fix this issue.
Closing as RESOLVED WONTFIX

> IMHO, 1.6 seconds [is] an acceptable delay.

That's an unrealistic way to think about the *increase* in file opening time. We're talking about 1.6 *EXTRA* seconds, probably on high-end hardware, and with no other CPU or disk-intensive tasks running in the background.

In the real world, the user is waiting 2.8 seconds for the file to open with Calc v5, and 4.5 seconds to open it with v6, in the best case scenario.

First off: Why? What's the gain to the user?

Second: by saying "X is an acceptable performance decrease", are we simply allowing software to get bigger and slower over time? By the way, 1.6 seconds slower than 2.8 seconds is a rather horrible drop in performance - almost 60% slower!

Third: there is a psychological threshold around the 3-second mark. Studies show that 53% of visits are likely to be abandoned if pages take longer than 3 seconds to load[1].

> It's not worth it to expend time and man power to fix this issue.

What causes this slowdown in v6? What features or refactoring were worth a 60% slowdown on opening a file? As a user, I don't see a compelling tradeoff to upgrade to v6 in exchange for the performance hit.

Also, what other areas of Calc are affected by this slowdown?


[1]: https://pinboard.in/u:dandv/b:aa61eb185929

Xisco, which commit is that? 
I'm in favor of more looking into this. Dan made a nice case here.
There are perf regressions all the time. Little by little and we are clogged.

(In reply to Timur from comment #14)
> This one? 
> https://gerrit.libreoffice.org/#/c/37926/ 

Yes, commit 1bb07b763560b7af64da27025b8f6299308b62a6 is that one (you may always lookup the commit on the cgit, appending its hash to URL like this: https://cgit.freedesktop.org/libreoffice/core/commit/?id=1bb07b763560b7af64da27025b8f6299308b62a6)

But that commit has nothing to do with the problem. And I don't see time difference between its performance and its parent; so must be bibisection error.

(In reply to Dan Dascalescu from comment #12)
> > IMHO, 1.6 seconds [is] an acceptable delay.

Well, the testing actually doesn't answer if this is acceptable. To answer that, an understanding required if that's some constant added to any lengthy open operation, or something different (like increasing proportionally, or adding to other operations, etc), Having said that:

> That's an unrealistic way to think about the *increase* in file opening
> time. We're talking about 1.6 *EXTRA* seconds, probably on high-end
> hardware, and with no other CPU or disk-intensive tasks running in the
> background.
> 
> In the real world, the user is waiting 2.8 seconds for the file to open with
> Calc v5, and 4.5 seconds to open it with v6, in the best case scenario.

Well, my testing shows different figures: 5.4 branch-off shows ~3.75s, while 6.0 shows ~4.05s. It's not some high-end system, with ordinary HDD (no ssd),  without closing multiple other applications in the background; but of course, the figures are taken after a number of trials, elimination the first one, so that I only measured the cached program state. So - observation #1: what you say is not a best case scenario, and the slow-down isn't that universal.

> First off: Why? What's the gain to the user?

Of course, the answer could be given only by finding the commit (I failed myself, when also tried to bibisect - my lookup ended with https://cgit.freedesktop.org/libreoffice/core/commit/?id=29c07c224d8b51ff9bf417eb2e3960cd0f9612fd, which also seems to have nothing with the problem). But take it for granted, that each commit has its beneficial goal; no commits are introduced with the specific goal to bloat things and make everything slower. Some commits may make things safer; other may prepare for e.g. increasing column count; yet other could fix bugs by introducing more checks. And even if you may not see the benefit from your PoV, it doesn't mean that there's none.

> Second: by saying "X is an acceptable performance decrease", are we simply
> allowing software to get bigger and slower over time? By the way, 1.6
> seconds slower than 2.8 seconds is a rather horrible drop in performance -
> almost 60% slower!

As I mentioned above, the measurements don't say nothing about actual slowdown - neither in absolute figures, nor in percentage. A fixed surplus would become negligible on larger data; or it may actually be significant. Don't try to manipulate random figures, as if they have more meaning than they actually bear.

> Third: there is a psychological threshold around the 3-second mark. Studies
> show that 53% of visits are likely to be abandoned if pages take longer than
> 3 seconds to load.

This has nothing to do with LibreOffice. A random site visitor behaviour differs from behaviour of a user who opens own/important data on own system. This is just absolutely irrelevant.

> > It's not worth it to expend time and man power to fix this issue.
> 
> What causes this slowdown in v6? What features or refactoring were worth a
> 60% slowdown on opening a file? As a user, I don't see a compelling tradeoff
> to upgrade to v6 in exchange for the performance hit.
> 
> Also, what other areas of Calc are affected by this slowdown?

I tried to answer this in principle. Yes, I still cannot point to specific commit, or even point out which systems suffer; and if you will take the task and find out that yourself (using bibisect[1] - in hope that you'll succeed) - it would be really helpful.

[1] https://wiki.documentfoundation.org/QA/Bibisect

When discussing on IRC, the point came up: is the increased time seen only during program startup? What if LibreOffice is already running, is the time still different?
The screencast shows the file being opened without a running LibO instance and Xisco confirmed he tested in the same way.

Well, I bibisected again using another system (a VM in VirtualBox, with 2 CPUs and 8 GB memory, on a Win host), and can finally confirm bisection results of Xisco from comment 11. Yes, seems that the update of those libraries did the slowdown.

Thorsten: given that there's now version 1.10.0 of gpgme, which is said to have "Reduced spawn overhead on Linux again", isn't it worth it to update for 6.1 and check if that would fix this?

BTW: in this last testing, the times were 3.2s vs 4.5s for time OOO_EXIT_POST_STARTUP=1, which includes starting, opening and exiting.

(In reply to Mike Kaganski from comment #18)
> Thorsten: given that there's now version 1.10.0 of gpgme, which is said to
> have "Reduced spawn overhead on Linux again", isn't it worth it to update
> for 6.1 and check if that would fix this?

Right, though I guess even better would be not pulling in gpgme at all if there's no digital signature. Can look into that, but can't commit to any timeframe.

(In reply to Thorsten Behrens (CIB) from comment #20)
> (In reply to Mike Kaganski from comment #18)
> > Thorsten: given that there's now version 1.10.0 of gpgme, which is said to
> > have "Reduced spawn overhead on Linux again", isn't it worth it to update
> > for 6.1 and check if that would fix this?
> 
> Right, though I guess even better would be not pulling in gpgme at all if
> there's no digital signature. Can look into that, but can't commit to any
> timeframe.

Ok, let's put it to NEW for the time being...

Possibly fixed in bug 118593 - please test.

Original reporter, we believe this is fixed with bug 118593 - any chance to test with the newest 6.1?

Dear Dan Dascalescu,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp