Incredibly slow editing of documents when connected to network

[Jason Bassett]

When editing a document using LibreOffice, the system locks up after every update typed. Lock up can be up to 30 seconds before control is returned to the user. I have found that this takes place even on documents located on the same physical machine, not just network hosted documents.

Problem does not occur if I disconnect form the SSHFS drive.

I can understand potential delay when editing a remote document but the connection to an SSHFS file server is affecting editing of locally held documents too.

Description: Ubuntu 14.04.1 LTS
Release: 14.04
libreoffice-writer: Installed: 1:4.2.6.3-0ubuntu1

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: libreoffice-core 1:4.2.6.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-35.62-generic 3.13.11.6
Uname: Linux 3.13.0-35-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.3
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Sep 7 12:15:10 2014
ExecutablePath: /usr/lib/libreoffice/program/soffice.bin
InstallationDate: Installed on 2014-05-08 (121 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[Davian818 (davian818)]

With recent master it takes several seconds to open the File menu for a first time.

[Momonasmon (momonasmon)]

Can't reproduce under Fedora 19 (64-bit).
Build ID: fd2d0bc88fe05b53f45658d82f29c02511ea90fa

[Barta-c (barta-c)]

I see no speed issue under Win7 64bit with:

Version: 4.2.0.0.alpha1+
Build ID: 43cab408cdc9e3489113790d0990e50ca40f0adc
TinderBox: Win-x86@47-TDF, Branch:master, Time: 2013-11-15_23:44:51

@Urmas
please download a more recent build and retest.
by the way, which exact Windows version do you use?

change status to NEEDINFO

[Q-james-n (q-james-n)]

Using Win 7 pro (Version 6.1 build 7601: SP1) with latest patches
Hdwre: i-7 8-core 16gb with 2-4 cores "free" CPU load in the low single digits
LO v4.2.1.1
LO load on system startup disabled
Default Options settings (memory, etc.)
After launch of calc
click on file
Wait 32 seconds! for File menu drop-down to appear.
Once loaded into memory, the other menus all appear in a timely fashion
Go to options
change the
  Graphics cash from 20 to 120 mb
  memory per object from 5.2 to 20mb
  check the Load LibreOffice during system startup checkbox
Now the delay goes from 32 seconds to 8 seconds on first attempt
Exit out of calc and restart calc. The initial opening now takes 2 seconds because something is staying in memory. Slow, but somewhat workable. Once loaded, hover over any of the pulldowns is very fast and snappy. The problem is with the initial load and some related memory management issues
This is a regression as the previous version that I used 4.1.4 worked fine with NO mods (all defaults)

[Q-james-n (q-james-n)]

(In reply to comment #3)
> Using Win 7 pro (Version 6.1 build 7601: SP1) with latest patches
A Windows Home Premium laptop (AMD V120 2.2ghz 8gb) that I have does NOT have the problem.

On the i-7 3.4ghz pc:
Deinstalled LO V 4.2.1.1

Installed old version 4.1.4.2

Initial response is immediate. NO delays whatsoever.

Reinstalled 4.2.1.1 over 4.1.4.2
Problem is fixed. Initial response is immediate. NO delays whatsoever.

I'm happy. Can't really explain the fix. This is resolved for me but may not be resolved for others.

[Barta-c (barta-c)]

I confirm no speed issue at all opening "File" menu with 4.2.1.1 under Win7x64.

let's mark this as RESOLVED WFM.

feel free to REOPEN if the issue comes back and if you find a constantly reproducible scenario

[Q-james-n (q-james-n)]

Just when you thought all was safe. It's back.
A few new observations:
I'm running 4.2.1.1
After running a while after starting and stopping calc a few times, I seem to be getting some memory leakage as I observe the system through Task Manager. At this point I have about 1 gb of memory unaccounted for. Generally the system at baseline will take up around 2gb and now it has 3 gb. A reboot will probably clean things up and everything will be cool and responsive--at least for a while until the critical threshold is reached.

The delay time is now around 40 seconds for the "file" pull-down menu to appear. A newly observed intervening indicator occurs at around 8 seconds when the top bar appears with "(not responding)". That message goes away once the delay is overcome and the menus are loaded and available in memory. From a high-level systems perspective, I'm guessing the Calc application is scrounging though the discarded memory looking for the menu and once it has waded through it all, it grabs some more memory and creates a new instance. So each time it does this, Calc gets bigger and bigger and slower and slower.

I suspect the reason it appeared fixed before--was due to my failing to follow the past behavior of starting and stopping multiple times with no reboot. I spoke too soon.

[Markbinner (markbinner)]

I get this problem with Writer in LibreOffice 4.2.2.1. I have never seen it in previous versions.
My setup is 32-bit Windows XP Pro & 4GB RAM.

[Q-james-n (q-james-n)]

Upgraded from LO V 4.2.1.1 to 4.2.2.1. No change. Time from click of "File" on menu bar to when the drop=down menu appears: 37 seconds!

[Q-james-n (q-james-n)]

Another symptom under 4.2.2.1. I wanted to eliminate the mouse driver so I used alt-<key> combos to navigate to the file pull down. I then down-arrowed and right-arrowed to the "recent documents" pull-down. The first time it was instantaneous. The second attempt took 38 SECONDS for the recent documents pull-down to appear. Again from a systems perspective, this appears to be a memory-management or cache-management related problem.

[Q-james-n (q-james-n)]

Upgraded from LO V 4.2.4.2 to 4.2.5.2. The problem appears resolved. Time from click of "File" on menu bar to when the drop-down menu appears: is near instantaneous. Hovering back and forth with the mouse over the top-level pull-downs (file, edit, view, etc.) works again without that disappointing "(Not Responding)" showing up in the Active Title Bar. Started and stopped calc multiple times and performance did not degrade.

[Q-james-n (q-james-n)]

This is like a Zombie movie. Just when you think it's dead... It's baaaack.
A new observation:
I'm running 4.2.5.2
Same config as 2014-03-06 but LO load on system startup enabled

After running scalc a while I closed out all instances. After a number of hours, I cranked up another scalc session. I did my usual click of "File" and then expecting the new and improved snappy behavior... I get nothing. The usual (Not Responding) in the title bar and about 30 seconds until I can get the file pull down to proceed to the next step.
Now this is where it is different. I click down to the recent documents item and click - nothing. The file pulldown goes completely blank (new behavior), and the recent documents list never shows up. Eventually after 30 seconds or so, because of cursor placement, the blinking cursor is in the Name Box. I even tried using Alt keys (Alt-F for the file menu) (Alt-u for the recent documents menu) and still have the 30 seconds in neverland. After that second wait I still never get to where I want to go (select a recent document to open).
The work around is to click the Open file Icon (Ctrl+O) and work your way around the recent files and folders hierarchy. It is time consuming, but it beats 2 rounds of 30-40 seconds of nothingness.

[Q-james-n (q-james-n)]

And one more new symptom: It now takes about ~30 seconds to close and save a spreadsheet.
I added scalc.exe to the list of excluded images in Microsoft Security Essentials with no obvious change in behavior. Still slow.

[Momonasmon (momonasmon)]

*** Bug 80801 has been marked as a duplicate of this bug. ***

[Davian818 (davian818)]

Still seen in 4.4.

[Jmadero-dev (jmadero-dev)]

REOPENED is reserved for a bug that:

1. a developer has marked as FIXED;
2. a developer is assigned to the bug that is marked as FIXED;

In this case the bug report was never independently confirmed so correct status is UNCONFIRMED. Thanks!

[mikefreeman (mike-freeman-studio)]

I can confirm that this also happens to me ever since updating to version 4.2. I'm currently using 4.2.6.2 on Linux Mint 17 64-bit.

Any time I start LibreOffice, the first time opening a menu (doesn't have to be File on my system), it takes 5+ seconds before it opens. After that, menus open instantly.

[Barta-c (barta-c)]

status NEW because of confirmation in the post above

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stewart (stewartcoad)]

Hi there,

I confirm that I am having a similar problem.

It seems to be erratic sometimes takes up to 5 seconds other times it is instant

My OS is Windows 7

[Weaselthatbites (weaselthatbites)]

Created attachment 107051
Process stack during Libreoffice File Menu pause

[Weaselthatbites (weaselthatbites)]

Comment on attachment 107051
Process stack during Libreoffice File Menu pause

Windows 7, 64 bit. I can confirm I also get this bug. It pauses for at least 5 seconds when you click on the File menu. Here is a process monitor capture of the stack. I am not very good at diagnosing it any further than this.

I was just wondering if this could be related to the fonts changes that Microsoft have been updating recently as it looks to be something to do with true type font buffer. I have no idea though.

Hope it helps.

[Weaselthatbites (weaselthatbites)]

Seems like I managed to solve my problems with the File menu. It was the recent document list. It had stored a networked document on the list, and it looks like it was searching for it. So when I cleared that list, the wait disappeared.

[Jmadero-dev (jmadero-dev)]

If others can confirm that this is the problem (file on network in recent documents) can someone update the title of the bug? We should have at least 1 other person from the thread confirm this is the issue.

[Mike Johnston (mikejohnston)]

I can confirm that this is a problem for me as well. The file menu takes many seconds to open the first time I open it. Subsequent attempts to open the file menu are instantaneous. Yes, there are network items in my Recent Documents. I am on 4.3.1.2.

[Barta-c (barta-c)]

edited summary notes

[Q-james-n (q-james-n)]

As one of the "original" victims of this behavior I have to chime in here. It appears that the "original" problem has been confused with a new problem starting around Comment 16.

Original problem: initial operation of pull-down menus is fast and snappy AT FIRST and then over time becomes slow and sluggish with massive delays (I was seeing 30-35 second delays on an i7-3770/16gb/Sata6

New Problem :initial operation of pull-down menus is SLOW AT FIRST and then once cache/network connections are made, the recent file pull-down is fast and snappy ("normal").

Do we need to somehow split this bug? It seems as though the original "bug" has been hijacked and the name mistakenly changed on 9/30. I'm not throwing stones at anyone. I'm just trying to bring in some clarity and have those who have the one problem described in the early comments stay here and those who are having the new problem create a new bug report.

[Info-fg (info-fg)]

Can confirm the original problem with the menu opening very slowly the first time has been completely solved in my case by deleting the menu item "recent documents" under the "File" menu. It seems, pulling this information up in the beginning is taking time and stalling the appearance of this menu the first time around.

[Q-james-n (q-james-n)]

I finally was able to put together a REPRODUCIBLE set of steps to create/cure the problem which should help a programmer propose a workable solution to the problem. I was messing around with my virus scanner and the LO memory settings the other day and was able to get fast menu response and thought I was on to something. Then today I observed the 30-40 second open and 30-40 second close/save.

Background
My thanks to <email address hidden> who put me on the right track on where to look.

Some of the following commentary may be speculative based upon personal programming experience and a lack of knowledge of what is under the hood in LO.

On my libreOffice main screen I have 21 thumbnails of documents I regularly open. ONE of these is a networked document that I open once a week. SOMETIMES the remote machine (a laptop) is OFF. SOMETIMES the remote machine is ON.

Symptoms
When the machine is OFF LO is unable to reach across the LAN to ping the file and create the thumbnail or otherwise perform behind the scenes preloading of some stuff into cache etc. to speed up anticipated future file operations. LO still appears to attempt to reach out to the file even though the system is offline. I would suspect there is some kind of network timeout that is being tripped that is in the 20-30 second range.

So when one attempts to startup LO, It pings all the files and builds the Recent Documents list. When it gets to the networked file that is unavailable (remote system is offline) a network timer is started and the recent file list build is suspended waiting on the network request. When the timeout threshold is reached (~30 seconds), the build resumes and is quickly completed.

Test 1 with remote system offline
Open let's say a spreadsheet and change one individual cell forcing a save. Close the file and click on the save button. The time to close, save, and get back to the LO main process window is in the ~35 second range.

I have been living with this behavior for 7 frustrating months.

Test 2 with remote system ONline
Turn the remote machine on and wait until you can see the disk where the file is located over the network with Windows Explorer or whatever.

Open that spreadsheet again. Time to open ~1 second!!! Change one individual cell forcing a save. Close the file and click on the save button. The time to close, save, and get back to the LO main process is in the amazing ~1 second range. This can get even more fun...

Test 3 with remote system taken offline prior to save
Open that spreadsheet again and change one individual cell forcing a save. Close the file and BEFORE YOU click on the save button, SHUTDOWN the remote computer. The time to close, save, and get back to the LO main process is back to a dismal 23 seconds im my specific case.

I have resorted to using an old copy of MS office when I know that the remote system will be off and the 30 second delays are going to be happening.

Proposed solution for the programmer.
One may want to add an option or two to steer this behavior--timing parameters and such.
Treat all networked files on the most recently used list asynchronously, on the first pass/build--skip them and fill them in on ...

[Weaselthatbites (weaselthatbites)]

Why is it showing my email address when logged in, but not when I sign out? When logged out its my user name, but when logged in it shows it as my email address. Could an admin please change that or give me some directions on how to change it. Thank you.

James - could you edit your comment and remove my email address please. Thanks.

[Jmadero-dev (jmadero-dev)]

Unfortunately LibreOffice has 0 control over the freedesktop infrastructure. You should report a bug against freedesktop.org and request whatever you want removed to be removed.

[Weaselthatbites (weaselthatbites)]

I did email them, but I would ask, what do you guys do about spammers? Are you telling me that if a spammer came on here, and litttered every thread with inane adverts to say viagra, it would remain in the thread until such time as a third party person who is not related to Libreoffice, came along an deleted it? Is this the official case?

If so, that seems a very weird proposition. Also the fact that the particular address leads to a great many different subscription services, but not much in the way of actual contact address to get something changed.

Any further help would be welcome.

[Richard Leger (richard-leger)]

Just to confirm, I am encountering the same issue in LO 4.3.2.2 (un-installed previous version, installed new one) in Windows 7 Pro 64bits (fully up-to-date).

As suggested in earlier comments, it seems that clearing the "Recent Documents" list do solve the issue.

In addition of delay when trying to open the File menu here are some of the symptoms:

- "(Not responding)" appears in the windows header after a short while and then disappear.
- Sometime the File menu does not open, you need to press a second time on File for menu to open it.
- This behaviour seems also to slow down opening and closing of the overall application.
- Sometime it takes time for application to be again available after Save/Save As the documents.

Hope that help.

[ubu Leno (ubuleno)]

I am noticing same behavior with smbfs. removal of ~/.config/libreoffice temporarily alleviates the problem

[zdena (hitman-6)]

Yes. The same for me. It is totaly unusable. Very, very slow!

[Libreoffice-7 (libreoffice-7)]

I can confirm the bug still exists in 4.3.5.2 under Windows 7 Pro 32-bit.

Clearing recent document list removes the delay.

[Davian818 (davian818)]

*** Bug 88018 has been marked as a duplicate of this bug. ***

[Jmgigandet (jmgigandet)]

Hi,

Same problem here. Win 7 pro x64, LO 4.3.5.2.
We use a NAS, so almost all our files are on network.
Opening File menu for 1s time is very slow. Sometimes it does not open at all, we need to reselect File Menu (popup instantly).
Closing a spreasheet also takes a very long time.

After clearing the recent document list, opening of File menu and closing of docuents, are fast.

Regards,
Jean-Marc

[Scott Howard (showard314)]

Also reported upstream:
"Bug 71447 - File menu takes long time to open when network files on recent documents list are offline"
https://bugs.documentfoundation.org/show_bug.cgi?id=71447

"Bug 87013 - LO performance when network drive is mounted over slow link"
https://bugs.documentfoundation.org/show_bug.cgi?id=87013

Great summary:
https://bugs.documentfoundation.org/show_bug.cgi?id=71447#c27

Workaround from upstream:
clear the recent documents list (File->Recent Documents->Clear List)

[Dave Jury (djury-e)]

I am also getting this problem using Ubuntu 14.04.

[Dr Michael Brooks (michaeljtbrooks)]

"Workaround from upstream:
clear the recent documents list (File->Recent Documents->Clear List)"

This doesn't work for me. Why? Because clicking on any item in the Recent Documents List, including "Clear List" actually just opens up the first Recent Document!!

Most enterprise users will load and work on files from network drives. This slow editing bug is really hurting us. I suggest you bump up the importance if LibreOffice aspires to attract business users.

[John Brooks (frogging101)]

I can confirm the "Clear List" workaround works. Linux Mint 16 64-bit, LibreOffice Writer version 4.2.7.2 Build 420m0(Build:2).

It's likely the remote documents that were in the list that cause a delay somehow.

[Mongolie2006-freedesktop (mongolie2006-freedesktop)]

Same problem with 4.3.6.1-4.mga4 (Mageia 4, KDE), with a delay of about 130s for opening or closing a document, or getting the "File" menu or the "Recent Documents" item ready. But all the "Recent Documents" where available, 6 of them trough NFS (I opened them one by one to check.), the other ones locally. Clearing the list solved the issue. 130s for such frequent actions is not a minor bug.

[Mezzo (mezzoman)]

Confirmed also with WebDAV protocol (davfs2) items in Recent Documents

Add WebDAV using davfs2 to the list of remote protocols that cause gradual slow down of LibreOffice operations. With a davfs2 mount point mounted, LibreOffice loads snappy at first, but after 3-4 davfs2 mounted documents it begins to slooow down on all operations, even typing. Clearing the Recent Documents speeds it right back up, as does unmounting the davfs2 mount point.

[Mezzo (mezzoman)]

Temporary fix until bug is solved:

Removing the "Recent Documents" from the File Menu temporarily fixes this issue so you don't have to clear the menu all the time. This is obviously not a real fix, but it gets people back to work:

Tools > Customize

Choose Menu > "File"

Select "Recent Documents" and click "Modify" on the right pull down and choose "Delete"

[Martijn Oldenburg (martijn-oldenburg)]

I have the same problems:
Ubuntu 14.04 LTS completely up-to-date with dist-upgrade
Libreoffice 4.2.7.2

Problem solved for me after removing "Recent Documents" from menu.

I have several fuse mounts in fstab. Only after a document from one of these mounts is in "Recent Documents" the delay while editting happens.

[Dr4K4n (stefan-dr4k4n)]

I can confirm the problem:
Ubuntu 14.04 LTS completely up-to-date with dist-upgrade
Libreoffice 4.4.2.2 (40m0 Build:2) from ppa:libreoffice/libreoffice-4-4

We use davfs2 to mount an owncloud share. Unmounting the share fixes the problem. Also removing the "Recent Documents" from the toolbar temporarily fixes the problem (Thanks @Mezzo!).

[Stzfan (stzfan)]

I'm also affected by this problem:
Ubuntu 14.04 LTS completely up-to-date with dist-upgrade
Libreoffice 4.4.2.2 (40m0 Build:2) from ppa:libreoffice/libreoffice-4-4

We use davfs2 to mount an owncloud share. Unmounting the share fixes the problem. Also removing the "Recent Documents" from the toolbar temporarily fixes the problem

[Petes-lists (petes-lists)]

I'm seeing this with LibreOffice 4.4.3 on Windows 7, at least when there is a list of files in the recently used list. I've also seen it with olderIt only happens when using OpenVPN and the VPN is connected, and there are files in the recently used list that are on the shared drive on the remote Samba server; when the VPN is disconnected the File menu works as expected.

I last saw this issue in October 2014 with LibreOffice 4.2.5.2-hotfix1.

Pete Boyd

[Martijn Oldenburg (martijn-oldenburg)]

Problem solved as of 4.2.8.2. Unknown if because of changes in LibreOffice or other packages. No changes in fuse mounts in fstab. Box is the same:
Ubuntu 14.04 LTS completely up-to-date with dist-upgrade as of 23 may 2015

[Roger Merchberger (zmerch7)]

I have 4.2.8.2 installed on Linux Mint 17 based on Ubuntu 14.04 LTS - and I am still experiencing the issue. It was researching the issue that led me to this thread, as a matter of fact. My system is completely up to date as of 3 Jun 15. Here's the build info: [[ Version: 4.2.8.2 Build ID: 420m0(Build:2) ]] if it helps. I have files mounted from a windows server share - and my current office only has a T1 (1.544 Mbit) for connectivity to the home office. Many mouse-based functions slow to a 20-60 second lag. Clearing out the recent files history does temporarily fix the problem - once I save the file and the file is now listed in the recent files, the problem returns.

Thanks!

[Q-james-n (q-james-n)]

Fixed under 5.0.0.5
Looking back at my previous comments from 2014-10-06 20:48:53 EDT and the test protocol presented, I tried to recreate the problem under 5.0.0.5. The PROBLEM IS SOLVED under the new version!!! When the query goes out, the response is nearly instantaneous AND the network accessed file is NOT PURGED from the list as it had in the past. The network accessed file is still there displayed. If you try and click on the file to open it (with the remote file server powered down), the system will come back after 20-30 seconds with a dialog box and say that the "file does not exist". Click OK. An hourglass remains. After one powers up the remote server clicking on the remote file icon brings up the file and opens it right away. This was the behavior we used to see before the bug showed up and the good (old) functionality has been restored. Thank you 5.0 team for whatever you did to restore the old and proper functionality. With this I close the ticket as resolved and fixed.

[Jmadero-dev (jmadero-dev)]

WFM is the right status since we don't know what fixed the issue. Thanks for reporting back!

[burnsdm (thepoolice)]

Confirmed the slow network connection for recent documents caused this to occur on my system

Linux Mint 17
Libre Office 4.2.8.2

Clearing recent documents seems to rectify this as a workaround

[penalvch (penalvch)]

Tested this from Xenial to Wily, not reproducible.

[Michael Korn (w-michael)]

some problem with VPN connections on Ubuntu 14.04

[Ertan Günay (ergunay)]

I'd like to notice another problem:
It doesn't slow as former but sometimes if you have Windows and Linux both and the xls or xlsx files edited on both OS, the file that you use becomes a very slow file to edit it.
A xlsx file that I use mostly became like that,
Than I've created e new blank file.
I copied too much data from old to new as text, not with format.
The new file was fast till copied comments.
After comments, it became as former file?
Do you have any solution for that.

Thanks in advance

[Machiel van Veen (machielvanveen)]

I can confirm this issue with Libreoffice version 5.1.4. I had a hard time reproducing the slow downs users where reporting to me but managed to recreate the conditions. I narrowed the problem to files listed in "Recent Documents" which are located on a file server (cifs).

With the list populated with about 10 items on the file server and about five open documents the effect is most noticeable. Typing and opening the menus will lag enormously, this will continue until you either clear the list of recent documents or remove it from the menu all together. The difference between a populated and a cleared list is like night and day.

The file server in question has decent performance but can take a second to respond if it is very busy. Either way, I do expect the first time listing on the menu to take some time. But the impact on overall performance is very unexpected and likely unintended.

[Narcis Garcia (narcisgarcia)]

No sense to report Windows cases (I feel that it's not the scope of Ubuntu bugs website).

I've been suffering this problem with SSHFS mounts too in Ubuntu 14.04 LTS (today Ubuntu 14.04.5 and LibreOffice 4.2.8.2). The only way to edit documents and have usable menus is to disconnect all SSHFS mounts.

As slower SSHFS mount is, slower LibreOffice works. No matter if you are working with only local documents.

[Mike Wilson (mwilson-e)]

I am experiencing this bug while using Ubuntu 16.10 with LibreOffice 5.1.4.2.
LibreOffice Calc takes a good 30 or so seconds to start when opening local files and pauses again for 30 seconds after every key press, this can be reproduced every time on my system by transferring a large file over to a SSHFS or SMB share and then opening any calc document. Once the transfer is completed or stopped libreoffice performs fine again.

[mickEDK (mickedk)]

Using Libre Office Version: 4.2.8.2 Build ID: 420m0(Build:2)
with my local network server mounted, all is well.
THEN
I unmount my local network server (or it dies for some other reason)
and Libre Office will only respond to keyboard or mouse
to the extent of being able to change 'highlighting' on the app menu.
Trying to edit file data or clicking menu items does nothing
File->Exit does not exit; no response from app.
(I can 'sudo kill <pid>' and reload app as a remedy.)
I have waited for hours to see if the problem persists: it does persist.
THEN
I mount my local network server
and all is well with Libre Office.
Clearly LibreOffice apps cannot tolerate disconnects of a local network drive.