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
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.
To be more precise, here is the current situation for any small file: .ods : 5[s] .odt : 5[s] .ddp : instant .xlsx : instant
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
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.
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
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...
Sorry for the name typo ;)
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.
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!
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)
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?
(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?
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.
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
I also did try to run this: strace /usr/bin/libreoffice But there is not call at all when I do open a document.
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%
Created attachment 114145 [details] strace logs of the bug Bug (huge lag) is between line 4034 et 4035.
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)
Created attachment 114146 [details] callgrind log file
Created attachment 114147 [details] cachegrind log file
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
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.
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
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
did you test with latest 4.4.5.2 or 5.0.0.5 releases?
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.
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?
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?
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.
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)?
(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.
@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.)
Migrating Whiteboard tags to Keywords: (perf)
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
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.
@NuageBleu what about you?
(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.
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)
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.
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 !
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 !
(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/
** 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
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.