[Libreoffice-bugs] [Bug 115325] Regression: Calc v6 opens .ODS file slower than v5

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=115325

--- Comment #16 from Mike Kaganski <mikekaganski at hotmail.com> ---
(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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180327/b7fb25ed/attachment-0001.html>