With recent master it takes several seconds to open the File menu for a first time.
Can't reproduce under Fedora 19 (64-bit). Build ID: fd2d0bc88fe05b53f45658d82f29c02511ea90fa
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
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)
(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.
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
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.
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.
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!
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.
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.
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.
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.
*** Bug 80801 has been marked as a duplicate of this bug. ***
Still seen in 4.4.
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!
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.
status NEW because of confirmation in the post above
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
Created attachment 107051 [details] Process stack during Libreoffice File Menu pause
Comment on attachment 107051 [details] 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.
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.
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.
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.
edited summary notes
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.
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.
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 weaselthatbites@yahoo.co.uk 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 a second pass AFTER the list is built AND displayed. At least two places will have to be treated this way: the File=> Recent Documents pull-down and the main LibreOffice screen with all the thumbnails. I hope this info helps provide a solution...
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.
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.
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.
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.
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.
*** Bug 88018 has been marked as a duplicate of this bug. ***
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
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.
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
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
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.
WFM is the right status since we don't know what fixed the issue. Thanks for reporting back!