Download it now!
Bug 79674 - Opening ods file is slow (empty/blank or not), xlsx file is fast [summary in comment 28]
Summary: Opening ods file is slow (empty/blank or not), xlsx file is fast [summary in ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks:
 
Reported: 2014-06-05 09:51 UTC by NuageBleu
Modified: 2019-02-17 21:02 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
strace logs of the bug (671.11 KB, text/plain)
2015-03-17 10:45 UTC, NuageBleu
Details
callgrind log file (1.81 MB, application/gzip)
2015-03-17 11:07 UTC, NuageBleu
Details
cachegrind log file (1.48 MB, text/plain)
2015-03-17 11:13 UTC, NuageBleu
Details
'callgrind_control -e -b' result (4.77 KB, text/x-log)
2015-03-17 11:19 UTC, NuageBleu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NuageBleu 2014-06-05 09:51:28 UTC
LibreOffice: 4.2.4.2
time to open a blank document:
.ods  : 5[s]
.xlsx : instant

Also:
- I read many bugs reports, looks like its a recurrent issue, sorry if I did miss one, but the last I found says it was fixed in 4.1, but
- Opening a larger document is not slower for me.
- Other opening speed issues where fixed with (sudo fc-cache -f -v)
- hardware is fast, and I used tmpfs for tests
Comment 1 NuageBleu 2014-06-05 15:44:58 UTC
I'd like to add that opening various .odt documents is again slow.
It looks like there is a "dead" 5[s], since when I open a document it waits
It is any instructions to provide a profiling?

There is no windows opening in these 5[s], no progress bar. When the progress bar is shown, it's very fast. I'm not using big documents.

It may be related to the windows manager, I'm currently using KDE 4.13.1.
This issue is only happening with LibreOffice tough.
Comment 2 NuageBleu 2014-06-05 16:13:14 UTC
To be more precise, here is the current situation for any small file:

.ods  : 5[s]
.odt  : 5[s]
.ddp  : instant
.xlsx : instant
Comment 3 Jean-Baptiste Faure 2014-06-09 16:09:05 UTC
What do you mean by "blank document"? A new empty document or an existing empty document ?

Please, could you describe step by step how do you proceed to compare times to open the files?

Set status to NEEDINFO, please set it back to UNCONFIRMED when you will have provided the requested informations.

Thank you for your understanding.
Best regards. JBF
Comment 4 NuageBleu 2014-06-10 11:20:14 UTC
I used "blank document" to refer to opening an empty saved document. Creating a new document (ctrl-n) is instant.

Procedure for .ods
1) Start LibreOffice
2) Create a new Calc (spreadsheet) document.
3) Save it.
4) Close it.
5) Open it. (work both trough KDE or the LibreOffice Open-menu).
6) I used my hand watch to count 5-6[s] before the document to be actually open.

Right now I have these speeds:
.ods  : 5-6[s]
.odt  : instant (so it's unstable, last time I measured it did hit 5[s])
.odp  : instant
.xlsx : instant

Also I just did try with java7 (my default) and java6, both with the same results.
Comment 5 NuageBleu 2014-06-10 11:22:39 UTC
Sorry that I didn't took time to read about LibreOffice developers, and how to contribute, but I have the java dev stack installed, so let me know it I can try something more technical.
Best regards
Comment 6 Firas Hanife 2014-06-25 22:45:48 UTC
Hi NaugeBleu,
could you please tell us which hardware are you using? Performance most times depends on it. I mean I use an ssd and don't have any delay...
Comment 7 Firas Hanife 2014-06-25 22:46:22 UTC
Sorry for the name typo ;)
Comment 8 NuageBleu 2014-06-26 08:03:49 UTC
As I said the hardware is fast:
- Intel Core i7-4750HQ CPU
- SSD 480GB (Crucial M500)
- 16 GiB RAM
And I double checked the test by saving files in /tmp, which is configured to use tmpfs, so it's using RAM.

Since Debian Testing is updating things all the time, my current version of LibreOffice is : Version: 4.2.4.2

Some more information:
I also use a VM with kubutu, which uses an other version of LibreOffice (Version: 4.2.3.3), which doesn't have this issue. So it cannot be the hardware.
Comment 9 NuageBleu 2014-06-26 08:25:32 UTC
More information:
Debian just updated the LibreOffice packages, so the new version I'm testing is:

Version: 4.2.5.2
Build ID: 420m0(Build:2)

Which *still* have the same problem.

So I Test again with small documents:
.ods  : 5[s]
.odt  : instant
.odp  : instant
.xlsx : instant if saved by LibreOffice, and 5[s] for another document

I hope this can help to track down the bug!
Comment 10 Buovjaga 2014-11-19 07:57:06 UTC
I can't reproduce on a VM, my system is about 1/3 as powerful as yours. An empty saved .ods opens instantly.

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: a55adb16ece70360c88342ca008d5a9d5b9d5b52
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-18_22:04:40

and

Version: 4.3.3.2
Build ID: 430m0(Build:2)
Comment 11 NuageBleu 2014-11-20 10:43:47 UTC
Testing again today.
Also updating priority as Jessie is getting its freeze.


1) On Debian Jessie, LibreOffice version:
Version: 4.3.3.2
Build ID: 430m0(Build:2)
Issue is *present*: just saving an empty .ods file takes 5-6[s] to open.
Also I just did try with both java6 and java7 (both openjdk).


2) On Ubuntu, LibreOffice version: (in a VM)
Version: 4.2.7.2
Build ID: 420m0(Build:2)
The issue is *not* present on this system, (so confirming last post and testing method).


It would be awesome to have some profiling, is anything possible?
Comment 12 Robinson Tryon (qubit) 2014-12-23 19:50:38 UTC
(In reply to NuageBleu from comment #11)
> 1) On Debian Jessie, LibreOffice version:
> Version: 4.3.3.2
> Build ID: 430m0(Build:2)
> Issue is *present*: just saving an empty .ods file takes 5-6[s] to open.
> Also I just did try with both java6 and java7 (both openjdk).

TESTING with LO 4.4.0.1 + Ubuntu 14.04
Saving empty ODS: 2 sec

Opening that ODS: < 1 sec
(I closed and reopened LibreOffice, too)

> 
> It would be awesome to have some profiling, is anything possible?

Tools like Call-/Cachegrind can be helpful here
https://wiki.documentfoundation.org/callgrind

Of course, we have to reproduce the bug before we can run such tools ourselves. What happens when you test TDF-provided builds? Do you see the same behavior as with Debian-provided builds?
Comment 13 NuageBleu 2015-03-17 10:21:43 UTC
I have 2 different computer, both with the same base system (Debian Jessie):
- One never have this problem.
- One usually have this problem.
So it's pretty clearly not related to the build, but to the computer state. Also before the Jessie freeze, I could try many different builds and they all had the issue.

So yesterday I had the issue, but today I cannot reproduce, as the document do open fast. I got valgrind ready and I'll post next time I have the issue.
Comment 14 NuageBleu 2015-03-17 10:26:58 UTC
Just a bit later, and now the bug is back.
Here is the callgrind result:

$ valgrind --tool=callgrind /usr/bin/libreoffice
==4837== Callgrind, a call-graph generating cache profiler
==4837== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==4837== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==4837== Command: /usr/bin/libreoffice
==4837== 
==4837== For interactive control, run 'callgrind_control -h'.
==4838== 
==4838== Events    : Ir
==4838== Collected : 365639
==4838== 
==4838== I   refs:      365,639
==4841== 
==4841== Events    : Ir
==4841== Collected : 413166
==4841== 
==4841== I   refs:      413,166
==4845== 
==4845== Events    : Ir
==4845== Collected : 437732
==4845== 
==4845== I   refs:      437,732
==4846== 
==4846== Events    : Ir
==4846== Collected : 664285
==4846== 
==4846== I   refs:      664,285
Comment 15 NuageBleu 2015-03-17 10:30:53 UTC
I also did try to run this:

strace /usr/bin/libreoffice

But there is not call at all when I do open a document.
Comment 16 NuageBleu 2015-03-17 10:39:54 UTC
Sorry, I messed up with the binnary to run. Now here are the results:
(but it looks like there is nothing interresing...)


------------------- callgrind results -------------------------------

$ valgrind --tool=callgrind /usr/lib/libreoffice/program/soffice.bin
==5068== Callgrind, a call-graph generating cache profiler
==5068== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==5068== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==5068== Command: /usr/lib/libreoffice/program/soffice.bin
==5068== 
==5068== For interactive control, run 'callgrind_control -h'.
==5068== 
==5068== Events    : Ir
==5068== Collected : 4338871667
==5068== 
==5068== I   refs:      4,338,871,667


------------------- cachegrind results -------------------------------

$ valgrind --tool=cachegrind /usr/lib/libreoffice/program/soffice.bin
==5114== Cachegrind, a cache and branch-prediction profiler
==5114== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote et al.
==5114== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==5114== Command: /usr/lib/libreoffice/program/soffice.bin
==5114== 
--5114-- warning: L3 cache found, using its data for the LL simulation.
==5114== 
==5114== I   refs:      4,042,935,140
==5114== I1  misses:        8,159,065
==5114== LLi misses:          360,653
==5114== I1  miss rate:          0.20%
==5114== LLi miss rate:          0.00%
==5114== 
==5114== D   refs:      1,638,119,052  (1,124,768,119 rd   + 513,350,933 wr)
==5114== D1  misses:       45,444,108  (   41,948,841 rd   +   3,495,267 wr)
==5114== LLd misses:        4,487,738  (    2,882,964 rd   +   1,604,774 wr)
==5114== D1  miss rate:           2.7% (          3.7%     +         0.6%  )
==5114== LLd miss rate:           0.2% (          0.2%     +         0.3%  )
==5114== 
==5114== LL refs:          53,603,173  (   50,107,906 rd   +   3,495,267 wr)
==5114== LL misses:         4,848,391  (    3,243,617 rd   +   1,604,774 wr)
==5114== LL miss rate:            0.0% (          0.0%     +         0.3%
Comment 17 NuageBleu 2015-03-17 10:45:54 UTC
Created attachment 114145 [details]
strace logs of the bug

Bug (huge lag) is between line 4034 et 4035.
Comment 18 NuageBleu 2015-03-17 10:48:12 UTC
Hoever, strace is way more interresting.
This command will show where it's blocking:
strace /usr/lib/libreoffice/program/soffice.bin

The output is huge. LibreOffice is blocked between first and second log lines:

futex(0x6616f64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1426588700, 15528000}, ffffffff
) = -1 ETIMEDOUT (Connection timed out)

(See attached document for all context. the bug is then occuring between line 4034 and 4035)
Comment 19 NuageBleu 2015-03-17 11:07:30 UTC
Created attachment 114146 [details]
callgrind log file
Comment 20 NuageBleu 2015-03-17 11:13:53 UTC
Created attachment 114147 [details]
cachegrind log file
Comment 21 NuageBleu 2015-03-17 11:19:29 UTC
Created attachment 114148 [details]
'callgrind_control -e -b' result

This was the result of this command executed in the meantime of the opening lag:
(It was executed when LibreOffice was hang at the opening of the ods file)

callgrind_control -e -b
Comment 22 NuageBleu 2015-03-17 11:21:55 UTC
Please also see the latest attached files:
1) callgrind_log_file
   With 'callgrind_control -e -b result', which could help
   tracking the issue as it displays a few stacktraces.
2) cachegrind_log_file
   I'm not sure how this can help much, but as it's requested, here you are.
Comment 23 Jean-Baptiste Faure 2015-08-02 09:48:05 UTC
I think the important information here is "KDE".
Is your computer connected to a network printer? In such a case please try to launch LO with the following environment variable set:

export SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true"

Best regards. JBF
Comment 24 NuageBleu 2015-08-03 12:49:52 UTC
Yes: my computer is attached to network printers, and it looks like there is some unrecoverable issue with its configuration. It makes also some other operations to be slow.

However when I did try to set the env var, it didn't help to make the .ods openning any faster.

SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true" libreoffice

Best Regards
Comment 25 tommy27 2015-08-17 17:03:55 UTC
did you test with latest 4.4.5.2 or 5.0.0.5 releases?
Comment 26 NuageBleu 2015-08-18 06:10:23 UTC
I had this bug for one year and one month on a regular Debian jessie. I thought I was helping by reporting issue to make LibreOffice better. But as I need my system to work I did reinstall it last week. As explained this was only affecting one system and not the other. I guess you can close the bug if nobody else can report it.
Comment 27 tommy27 2015-08-18 13:26:42 UTC
what did you reinstall? the Linux O/S or LibO? and what about the bug with the current configuration (tell exact versions)? do you still see it or not?
Comment 28 Francisco Pina Martins 2015-08-18 23:10:02 UTC
Just confirming that this is also affecting me.
Although in my case, only .ods files are affected, and not .odt.
My lag is also a bit larger than what the OP was reporting. My .ods file takes about 30s to load, while the same file, saved with a .xlsx extension open instantly.
My system:
Archlinux (current as of today)
Libreoffice 4.4.5
Also, unlike the OP, I'm not on KDE, but rather on Gnome-shell 3.16.
Finally, I do have network printers attached to my system. Running:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true" libreoffice /path/to/file.ods
Does make the .ods file loading instant.
So, what's happening here? Why does it only happen on .ods files and not on .xlxs?
Comment 29 NuageBleu 2015-08-19 06:53:45 UTC
I did reinstall the full system (disk wipe and clean fresh install).

The LibreOffice version on Debian Jessie (8) is currently 4.3.3.2.

Now the issue has now disappeared on the system.

As I wrote earlier, this was expected as: I have two very similar computer, each of them having a regular Debian Jessie (8), each have network printer, but only one had this issue.
Comment 30 Buovjaga 2015-08-19 07:02:11 UTC
Ok, it might have been a corrupt profile issue or something completely different.

Francisco: do you mean the same happens with every .ods file? Even a blank document (as this report was originally about)?
Comment 31 tommy27 2015-08-19 13:46:16 UTC
(In reply to Francisco Pina Martins from comment #28)
> Just confirming that this is also affecting me.
> ...

please answer Beluga's questions and if the issue is just about a specific .ods file please open a new separate report.
Comment 32 Francisco Pina Martins 2015-08-19 22:10:56 UTC
@Beluga and @Tommy27:
Yes, it happens even on an empty, just saved .ods file.
To make it open fast, I can either launch calc with the mentioned workaround (SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true" libreoffice /path/to/file.ods) or save it and open it as a .xlsx file (ugh!).

Is there any further information I can provide that may be relevant? (backtraces, etc? If yes, please point me at some docs on how to do it, as it will be a first time for me.)
Comment 33 Robinson Tryon (qubit) 2015-12-09 18:07:50 UTC Comment hidden (obsolete)
Comment 34 QA Administrators 2017-01-03 19:41:46 UTC Comment hidden (obsolete)
Comment 35 Francisco Pina Martins 2017-01-03 23:16:44 UTC
I can no longer reproduce on 5.2.4, although I have since modified my printer configuration, so that could be the reason. Therefore I'm not changing the status.
Comment 36 tommy27 2017-01-03 23:30:38 UTC
@NuageBleu
what about you?
Comment 37 Buovjaga 2017-01-04 08:28:06 UTC
(In reply to tommy27 from comment #36)
> @NuageBleu
> what about you?

Well NuageBleu could not reproduce it since switching systems (comment 26), so at the moment we have zero people who can verify this. Let's close.
Comment 38 NuageBleu 2017-01-05 10:57:35 UTC
So it has been indeed working for some time.

But then the bug happened again. I think in November 2016.
(I'm still on a Debian stable)

So this thread helped me:
https://ask.libreoffice.org/en/question/21335/opening-ods-file-very-slow/

So I'm currently using the WORKAROUND:
Add this to .profile
export SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true".


I'll now try to see if this workaround can be disabled...

(So for me, this bug wasn't dead for a year)
Comment 39 NuageBleu 2017-01-05 11:02:55 UTC
One one of my two system, the workaround can be disabled.
(That's one printing configuration)

The other system is at another place, so I'll try it later.
(and reopen if occurring)

Anyway, it's looking good so far.
Comment 40 NuageBleu 2017-01-05 20:38:38 UTC
So, no issues is occurring on any of my system today.
I have to confirm that the issue happened again in November.

Anyway, thanks for the work of all devs and fixers !
Comment 41 NuageBleu 2017-01-09 08:03:11 UTC
Sorry, on a freshly installed system the problem is still here, or at least, extremely similar. Let me know if this is different enough to open a new bug.

This is the time to open an empty document for the first time:

1) Without workaround:
.odt  : instant
.ods  : 22-24 [s]
.xlsx : instant

2) With workaround:
.odt  : instant
.ods  : instant
.xlsx : instant

Again, the workaround is:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true"

For instant to add this in your .profile
export SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION="true"

Currently my LibreOffice version is: 4.3.3.2

Thanks !
Comment 42 Buovjaga 2017-01-09 10:02:46 UTC
(In reply to NuageBleu from comment #41)
> Currently my LibreOffice version is: 4.3.3.2

Please test with version 5.2.4 like Francisco

https://wiki.documentfoundation.org/Installing_in_parallel/Linux
http://www.libreoffice.org/download/libreoffice-fresh/
Comment 43 QA Administrators 2018-01-10 03:31:57 UTC Comment hidden (obsolete)
Comment 44 Cor Nouws 2019-02-17 21:02:52 UTC
dear people,

The older reports that have be checked again, seem to be resolved.
It definitely is not a general problem.
So if anyone has this again, it must be due to very very specific circumstances. Good to try to find that out then - preferably in a new report.