Bug 81640 - Very slow and lagging if open file stored on network
Summary: Very slow and lagging if open file stored on network
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
Depends on:
Blocks: Network
  Show dependency treegraph
Reported: 2014-07-22 09:49 UTC by Sumec
Modified: 2021-11-10 14:43 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Sumec 2014-07-22 09:49:15 UTC
After update LibreOffice from 4.2.3 to 4.2.4-> I have problem with documents stored on network.
If I open any file stored on network (diskstation NAS Synology), LO is very slow in work. Clicking, scrolling and typing is very lagging. It doesnt matter how large is the file and type of this (xls, doc..). LO stay lagy until restart PC, then is OK again.
If I open file stored in my local PC, this is OK, but after I open any network stored file, problem is again..

My PC configuration - Dell Optiplex 780, Intel C2D 3.0GHz, 4GB RAM
Ubuntu 14.04 64bit, kernel 3.13.0-32 generic.

Sorry for my bad English

Many thanks
Comment 1 Jean-Baptiste Faure 2014-07-22 10:24:09 UTC
Please could try with 4.3.0 RC3 or 4.2.6 RC1 from https://www.libreoffice.org/download/pre-releases/. It is a mean to bound the problem and find if it is in the Ubuntu build or in the mainstream version. Installing RC on Linux should make this installation in parallel with your stable version.

Set status to NEEDINFO. Please set it back to UNCONFIRMED once you have provided requested informations. Thank you for your understanding.

Best regards. JBF
Comment 2 Sumec 2014-07-23 05:56:23 UTC
Thanks you answer. I tried both of version you are posted in link, but there is the problem - now opening files stored on network isnt possible. Locale stored files - Ok, but if I try to open any file on network, nothing happens. Other LO version I removed before installation.
Comment 3 Jean-Baptiste Faure 2014-07-23 06:44:24 UTC
OK. Continuing to try to bound the problem: there two available dialogs to open a file, the dialog provided by the system (Nautilus in your case) and the dialog provided by LibreOffice. You can switch from one to the other in the LO options : menu Tools > Options > LibreOffice > General.

Please, could you try the LibreOffice dialog to see if that changes something?

Set status to NEEDINFO. Please set it back to UNCONFIRMED once you have provided the requested informations.

Best regards. JBF
Comment 4 Sumec 2014-07-23 07:19:11 UTC
I tried this, but nothing changes... If I want open file from Nautilus, LO is starting, but after few seconds take off. And if I want open file from LO dialog, nothing happens..
Comment 5 Sumec 2014-07-23 08:58:50 UTC
This is line in system log, if help this:

08:56:11 petr-OptiPlex-780 kernel: [ 6113.156248] soffice.bin[9968]: segfault at 10026e7fd0 ip 00007febd438b764 sp 00007fff17163770 error 4 in libfps_officelo.so[7febd4339000+5e000]

Jul 23 10:50:49 petr-OptiPlex-780 kernel: [12991.438887] soffice.bin[13223]: segfault at 1a ip 00007feb1bb5a6d0 sp 00007fff38de8490 error 4 in libvcllo.so[7feb1b730000+669000]

Best regards Sumec
Comment 6 Joel Madero 2014-07-27 02:00:29 UTC
@Sumec - could I walk you through bibisecting this as I think finding someone to confirm may be tough. If you're willing to do this please check out: https://wiki.documentfoundation.org/QA/HowToBibisect
Comment 7 alci 2014-11-26 19:22:17 UTC
I can see the same behaviour, using Calc version on Ubuntu 14.10.

LO becomes almost unusable, and network traffic keeps up. Only when it goes down for a few seconds can I type or scroll, then network traffic goes up again and LO freezes.

Same files stored locally work just fine.
Comment 8 tommy27 2014-11-26 19:36:12 UTC
status NEW because of confirmation in post above
Comment 9 QA Administrators 2015-12-20 16:21:34 UTC Comment hidden (obsolete)
Comment 10 Stéphane Aulery 2016-03-03 16:14:18 UTC
Tested and confirmed with version 5.0.1 on Debian.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774399#37

> I've just tried 1:5.0.1-2~bpo8+1 and found it definitely better comparing to 
> what it used to be. However it is still not ideal -- for example editing a 
> spreadsheet lags after modifying a cell and clicking another cell...
Comment 11 cedric321 2016-04-01 23:16:08 UTC

Like i report here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774399

I have seen another reason of slowness,very slowprocess  of Libreoffice.
The problem arrives without nfs sharing.
I see the problem with "Jessie Libreoffice 4.3.3-2+deb8u3" and with "fr.libreoffice.org LibreOffice 5.0.5".

If you have for example an file in a directory : /home/toto/Documents/file.odb

If you do:
$ ln -s /home/toto/Documents/file.odb /home/toto/Desktop/file
$ ln -s /home/toto/Documents /home/toto/Desktop/Documents
an other "ln -s" to access to the file

If you open the file trough /home/toto/Desktop/file or /home/toto/Desktop/Documents (tested with a file browser), the problem arrives.

It seems that Libreoffice don't like open a file trough a directory that is not the real file directory.

Comment 12 QA Administrators 2018-01-31 03:42:52 UTC Comment hidden (obsolete)
Comment 13 cedric321 2018-02-01 09:46:54 UTC

Still present in LibreOffice
If you do :
$ ln -s /home/toto/Documents/file.odb /home/toto/file.odb

Thank you.

Build ID: 1:5.2.7-1
Comment 14 QA Administrators 2019-02-06 03:50:52 UTC Comment hidden (obsolete)
Comment 15 Alan Howlett 2019-03-31 16:52:05 UTC
I am running the latest Manjaro with LibreOffice:
Build ID: 6.2.2-1
CPU threads: 12; OS: Linux 4.14; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

I have no performance problem with LibreOffice against my local disk. My network is 1Gb/s, I am the only user, with a 4-disk Diskstation as our server. Performance is really slow over the network. Anything I am actually working on gets copied to my local disk so it is much faster.

Thank you guys for working on these issues & making my life better.
Comment 16 Alan Howlett 2019-03-31 17:28:35 UTC
So... I did a test with a file on the network called "Directions.doc". I saved it to .docx and .odt, then saved the .odt to Directions2.doc to see if the problem was the file format.

I opened the file by clicking on it in Dolphin:
Directions.doc - 2 seconds.
Directions.docx - 32 seconds
Directions.odt - 32 seconds
Directions2.doc - 2 seconds

All these files open "instantly" on the desktop, but on the network there is clearly a problem, which suggests something like excessive I/O's which choke the network.

I have been experiencing this for a least 2 years I think, but have only just seen that it is associated with the file suffix. I have reproduced this problem a few times in doing this note and it seems consistent, so it's not an issue with the network or disks going to sleep.

I hope this helps.
Comment 17 Jean-Baptiste Faure 2019-03-31 19:51:45 UTC
odt and docx are archive files, in fact zipfiles renamed in .odt or .docx.
doc files are binary files. Could you try if opening zipfiles (with .zip extension) stored on the network is slow too ?

Best regards. JBF
Comment 18 eric 2019-05-08 23:02:21 UTC
I'm having exactly the same bug and it has been going on for a while with all the versions within the past year or so. It is simply unusable to open a ODT document on our Samba server. I have to copy it to my local machine to edit it. It's faster to access it from remote by SSH than it is on our LAN. It's a complete usability disaster. The Samba server is on Ubuntu 1604, 4.3.11-Ubuntu. Whatever interaction is causing this, it should be fixed as a top priority.
Comment 19 Jean-Baptiste Faure 2019-05-09 07:28:43 UTC
Please do not change the version number which is showing the earliest version in which the bug has been reproduced.

Best regards. JBF
Comment 20 polndjv 2020-08-19 09:04:50 UTC Comment hidden (spam)
Comment 21 Flycpherson 2020-08-27 10:28:19 UTC Comment hidden (obsolete)