Description: Libreoffice was always very quick to start and open files on my MBP i7 16GM RAM 1T SSD. Since the upgrade to the v7.3.x family, the start-up takes much longer. Opening files takes 5+ sec. It used to open files nearly instantaneously. Steps to Reproduce: 1. Click on Libreoffice icon to start application 2. Open any file. Actual Results: It takes over 5 seconds to open the application. Opening a file takes 5+ seconds. this is much longer than the 7.2 branch which I estimate to be in the 1-2 sec. Expected Results: Libreoffice 7.3 branch should start-up and open files as quickly as the 7.2 and previous branches. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: As stated above, upto and including the 7.2 branch for MacOS Intel, Libreoffice started and opened files very quickly. Since 7.3.0 Libreoffice start-up and open files is considerably slower. Something has changed in the Mac version. My suspicion is that it's the display of the file as the progress bar shows the file has opened but you can't see anything until 5+ seconds.
I see there was a request for comments. Please let me know what you wish to know and I'll endeavor to collect the requested info.
Does this happen for you with any file, or only with certain files? If this only happens for certain files, would you be able to attach one to this bug report? That would help to debug this further. Be sure to remove any private or proprietary information first.
Hello and thank you for looking into this. Unfortunately it isn't one specific file but rather every file. I don't use Impress very often so can't comment to those. The initial start up of Libreoffice is about 5 sec. This is about usual. I don't have the startup when booting enabled so LO isn't running in the background. The first document opening after the initial start up of LO is particularly slow. After the first document has started and has been closed, a 20 page text document or a 161kb Calc doc both take 5-6 sec to load. The header/name of the document show up quickly but the actual showing of the document takes over 5 sec. I have noticed that every Calc document appears to have some messaging just below the toolbar now. The "help out Libreoffice" or "Automatic updating hasn't been enabled" both are new. I don't remember The "help out Libreoffice" showing up very often in the past, but the "Automatic updating hasn't been enabled" pops up with every Calc doc. I wondering if this additional code creates some of the slowdown? I don't know if this is helpful. I don't think sharing a file will help since it happens on every file.
[Automated Action] NeedInfo-To-Unconfirmed
Is your computer: * connected to the internet * connected to a network that is not connected to the internet; or * not on a network at all? Do you have a proxy set? LO should work in these different cases, but there have been other reports of issues when LO is not on the internet or the connection is through a proxy.
Yes, my computer is connected to a server which is then connected to the internet. There is no proxy running. I'm curious to understand how that would affect the local installed version of LO on my MBP. LO shouldn't be checking the internet except to check the version and if an update is available when it starts. I do get a notice when an update is available. But, I don't think it should be going to the internet every time I open a file. But my privacy thoughts aside, version 7.2 didn't have this issue. My server and network have had no changes except for the typical virus updates and automated blocking of potential intruders. The operation of the server and network is as before and should have no influence in my case. I hope this is helpful.
> I'm curious to understand how that would affect the local installed version of LO on my MBP. It may not. I'm just trying to see if the problem you are seeing is similar to some other old bugs. But this may be a completely different issue. As it is, I am not having this problem on my Mac laptop.
I have the same observation: version 7.3 is substantially slower than previous versions. It doesn't matter whether I click on an csv, ods or odt file: in all cases is the startup very slow compared to previous versions. My computer is using Ubuntu 22.04 as OS. LO 7.3 was installed as part of the upgrade from Ubuntu 20.04 to 22.04. Before the Ubuntu upgrade I used an older version of LO, which was substantially faster.
Please turn off proxy, to check if bug 135754. Joe, please see Ubuntu bug 150479.
There is no proxy running so there is nothing to turn off in my case. BTW, I updated to 7.4 and the slow start and slow file open is still continuing. I have also updated from macOS 10.14.6 to 12.5.1. The slow start and slow open happens on the new OS version also.
@bunkem: Could you install LibreOffice nightly build and see if the problem persists using that build: https://dev-builds.libreoffice.org/daily/master Note: To open LibreOffice nightly on macOS please refer to: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616 For it it opens in under or around 4 seconds.
If bunkem or Joe are able to, and the difference in performance is very obvious, it would be great if you could bibisect the issue to determine when exactly the degradation started. Instructions are here: https://wiki.documentfoundation.org/QA/Bibisect/macOS The repository you need is bibisect-mac64-7.3. If you need assistance with the process, please contact the QA team: https://wiki.documentfoundation.org/QA
Hi. I'm going to try this bibisect. I'm learning as I go and will have questions. This afternoon, I downloaded 7.2.5 again and tested it on MacOS 12.6.3. It is so fast, it is unbelievable. So this change happened between 7.2.5 and 7.3. 7.5.0.2 is as slow as 7.3. So I hope this bibisect can determine what changed and then it can get fixed.
Hmm. I don't think I did this right. git bisect good 846a5c424a6c16dc07eefb6827b362efed5075b1 is the first bad commit commit 846a5c424a6c16dc07eefb6827b362efed5075b1 Author: libreoffice <libreoffice@libreoffices-Mac-mini.local> Date: Tue Dec 21 03:15:32 2021 +0100 source ce69f71983a09416514f0569c6cdfbcde87d4b99 source ce69f71983a09416514f0569c6cdfbcde87d4b99 LibreOffice.app/Contents/Frameworks/libswlo.dylib | Bin 19027692 -> 19027692 bytes LibreOffice.app/Contents/Resources/setuprc | 2 +- LibreOffice.app/Contents/Resources/versionrc | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) The last version seems to be OK. From the Get Info it is 7.3 beta. However I found the issue originally in 7.3.3.2. Can you confirm that the bibisect-mac64-7.3 is the right one to test?
bunkem: just to be clear, before starting a bisecting session, you check both the master commit and the oldest commit in the repository. If the bug is not seen in the oldest, but is in master, you can start. Now, if you have doubts about the result, you can double-check by doing git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1 Test, if the slowness is there. Then, do git checkout HEAD^ to go to the preceding commit and test again. If the slowness is still there, your result is wrong. At least there is *some* plausibility regarding Jim's commit as it was adding an extra check in a loop, but I guess the loop should run a huge number of times in order to show such a slowdown.
Created attachment 185410 [details] my prefs from 7.2
Created attachment 185411 [details] my 7.3 prefs
(In reply to Buovjaga from comment #17) > bunkem: just to be clear, before starting a bisecting session, you check > both the master commit and the oldest commit in the repository. If the bug > is not seen in the oldest, but is in master, you can start. > > Now, if you have doubts about the result, you can double-check by doing > > git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1 > > Test, if the slowness is there. Then, do > > git checkout HEAD^ > > to go to the preceding commit and test again. If the slowness is still > there, your result is wrong. > > At least there is *some* plausibility regarding Jim's commit as it was > adding an extra check in a loop, but I guess the loop should run a huge > number of times in order to show such a slowdown. Thank you. I'll try this again. Could it be something to do with the Skia library introduction in v7.3? I noticed that I've disabled the Skia library along the way. When I enable in v7.3.3, it is slow to open. I don't have Skia library enabled in 7.5.2 either. When I enable it, LO starts slower. There is a delay in the opening of LO all versions from 7.3. 7.2 starts up noticeably faster. On the 7.3 start up, the pizza wheel spins for a bit, then the LO splash screen flashes by and then it opens to the Start Center. The second time I open any version it opens faster but usually around 5 seconds. I've added the preferences in both 7.2 & 7.3 to show the differences. Not sure if this is helpful???
(In reply to bunkem from comment #20) > Could it be something to do with the Skia library introduction in v7.3? It certainly could, but I understood from your comments that there is a slowdown compared to 7.2 regardless. Skia on macOS needs a bit more polish, so it's not active by default in 7.5. We're getting there, though.
(In reply to Buovjaga from comment #17) > bunkem: just to be clear, before starting a bisecting session, you check > both the master commit and the oldest commit in the repository. If the bug > is not seen in the oldest, but is in master, you can start. > > Now, if you have doubts about the result, you can double-check by doing > > git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1 > > Test, if the slowness is there. Then, do > > git checkout HEAD^ > > to go to the preceding commit and test again. If the slowness is still > there, your result is wrong. Hi again. Sorry I've tried to follow the instructions on the QA website link. THis is the first time I use git so I'm a bit lost. I followed the instructions and did: > git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1 > open Libreoffice.app/ It takes about 9-10 sec to start. So this is a slow one. > git checkout HEAD^ gives > Previous HEAD position was 846a5c424 source ce69f71983a09416514f0569c6cdfbcde87d4b99 > HEAD is now at a5a14a421 source b8f067dae3424c9cc2373e84c8a3465d477f9adc I don't know how to identify the last version. I presume it is 846a5c424 but that is the first 9 characters of the version checked out. I'm embarrassed for my lack of knowledge and the git bisect man page isn't helping me. :-(
I tried the git bisect log. Here for your info. --- git bisect log # bad: [2668193da8e1844ae0336dc59d3c93c6658f5d55] source ff2ba77f22b2e96f96f5537aec1705956b47583d git bisect start 'oldest' # status: waiting for good commit(s), bad commit known # bad: [846a5c424a6c16dc07eefb6827b362efed5075b1] source ce69f71983a09416514f0569c6cdfbcde87d4b99 git bisect bad 846a5c424a6c16dc07eefb6827b362efed5075b1 # status: waiting for good commit(s), bad commit known # good: [2668193da8e1844ae0336dc59d3c93c6658f5d55] source ff2ba77f22b2e96f96f5537aec1705956b47583d git bisect good 2668193da8e1844ae0336dc59d3c93c6658f5d55 # good: [dfbe4cd519bc2ac68dc5983edefbe101971f0db5] source 2284be4f80664c54fa2ef8652030aa14d63c13a2 git bisect good dfbe4cd519bc2ac68dc5983edefbe101971f0db5 # good: [a618a57be399fd8cef923fd9b4b67762a54523dd] source 3d7fcf663ceece43b4648e6adee19dc6869729af git bisect good a618a57be399fd8cef923fd9b4b67762a54523dd # good: [673f2ac9ffb2a66e4c72036865f7ba14383f96df] source ce64e3feb72dbe8f14a5b22a6a02722b02b391b0 git bisect good 673f2ac9ffb2a66e4c72036865f7ba14383f96df # good: [1e9e78204356ea7bcf442424bad2dcb309562ad5] source 3c62f72d7eda7a2d377cf45490c8c67403d8d745 git bisect good 1e9e78204356ea7bcf442424bad2dcb309562ad5 # good: [8bedbddcf0d17aff8bb71116f8be67b28ae0ddfe] source 965e6308522a21e77a4b19cafd018973b4097224 git bisect good 8bedbddcf0d17aff8bb71116f8be67b28ae0ddfe # good: [e1d97ac3e129e2c5f26b55edc48ea560f4fd8c50] source b5eecfc708316c1d5603f5235b408ce9fc19156d git bisect good e1d97ac3e129e2c5f26b55edc48ea560f4fd8c50 # good: [346775956106e07b0e62a1fa23ad07c52d18f1e1] source fd06b1b2689d4189fd94beade3983af4acc5ffc3 git bisect good 346775956106e07b0e62a1fa23ad07c52d18f1e1 # good: [e6e12dad792f4d2cbc690346b3115a8a8dc053df] source f4ba4c014c74d1735288fe356878d6a2effab21f git bisect good e6e12dad792f4d2cbc690346b3115a8a8dc053df # good: [6d2009e0522c58af3fa35929e2ff188c04d91e12] source 7f791573ff32bfb5bdd082b9a23413da6ff26b76 git bisect good 6d2009e0522c58af3fa35929e2ff188c04d91e12 # good: [4b6d46d5288e2e83dae822744d3bf3e30ad12658] source 68fdfc6013126526f5ba3908c5ad762f18f463cf git bisect good 4b6d46d5288e2e83dae822744d3bf3e30ad12658 # good: [1f020ca63c2be31f94eda95f5ce38ffb7c157349] source dd5e7b2120898b96132ed4d330adb597991c1f6b git bisect good 1f020ca63c2be31f94eda95f5ce38ffb7c157349 # good: [a5a14a42123e566a202fbb91103ae8c41dbb36e1] source b8f067dae3424c9cc2373e84c8a3465d477f9adc git bisect good a5a14a42123e566a202fbb91103ae8c41dbb36e1 # first bad commit: [846a5c424a6c16dc07eefb6827b362efed5075b1] source ce69f71983a09416514f0569c6cdfbcde87d4b99 --- How would I start again to check as I've learned a bunch over the past couple of hours?
(In reply to bunkem from comment #22) > (In reply to Buovjaga from comment #17) > > bunkem: just to be clear, before starting a bisecting session, you check > > both the master commit and the oldest commit in the repository. If the bug > > is not seen in the oldest, but is in master, you can start. > > > > Now, if you have doubts about the result, you can double-check by doing > > > > git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1 > > > > Test, if the slowness is there. Then, do > > > > git checkout HEAD^ > > > > to go to the preceding commit and test again. If the slowness is still > > there, your result is wrong. > > Hi again. Sorry I've tried to follow the instructions on the QA website > link. THis is the first time I use git so I'm a bit lost. > > I followed the instructions and did: > > > git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1 > > > open Libreoffice.app/ > > It takes about 9-10 sec to start. So this is a slow one. > > > git checkout HEAD^ gives > > > Previous HEAD position was 846a5c424 source ce69f71983a09416514f0569c6cdfbcde87d4b99 > > HEAD is now at a5a14a421 source b8f067dae3424c9cc2373e84c8a3465d477f9adc > > I don't know how to identify the last version. I presume it is 846a5c424 > but that is the first 9 characters of the version checked out. > > I'm embarrassed for my lack of knowledge and the git bisect man page isn't > helping me. :-( So to put it briefly, I'm interested in if you saw the slowness or not after running LibreOffice after doing git checkout HEAD^
Yes. It was slower. Rough estimate for comparison. Normal start up v7.2 2-3 sec; file open 2 sec Slow start up v7.3 9-10 sec; file open 5 sec.
(In reply to bunkem from comment #25) > Yes. It was slower. > > Rough estimate for comparison. > Normal start up v7.2 2-3 sec; file open 2 sec > Slow start up v7.3 9-10 sec; file open 5 sec. If you mean to say that startup was equally slow after 'git checkout 846a5c424a6c16dc07eefb6827b362efed5075b1' and 'git checkout HEAD^', then your bibisect result is not valid.
(In reply to Buovjaga from comment #26) > (In reply to bunkem from comment #25) > > Yes. It was slower. > > > > Rough estimate for comparison. > > Normal start up v7.2 2-3 sec; file open 2 sec > > Slow start up v7.3 9-10 sec; file open 5 sec. > > If you mean to say that startup was equally slow after 'git checkout > 846a5c424a6c16dc07eefb6827b362efed5075b1' and 'git checkout HEAD^', then > your bibisect result is not valid. Sorry about that. Last week was my first time using git. While I read the instruction in the link and also read a good portion of the git pdf, I still can't visualize what I'm doing. Perhaps the other individual can give this a try and I don't seem to be able to get it right.
(In reply to bunkem from comment #27) > (In reply to Buovjaga from comment #26) > > (In reply to bunkem from comment #25) > > > Yes. It was slower. > > > > > > Rough estimate for comparison. > > > Normal start up v7.2 2-3 sec; file open 2 sec > > > Slow start up v7.3 9-10 sec; file open 5 sec. > > > > If you mean to say that startup was equally slow after 'git checkout > > 846a5c424a6c16dc07eefb6827b362efed5075b1' and 'git checkout HEAD^', then > > your bibisect result is not valid. > > Sorry about that. Last week was my first time using git. While I read the > instruction in the link and also read a good portion of the git pdf, I still > can't visualize what I'm doing. > > Perhaps the other individual can give this a try and I don't seem to be able > to get it right. If you want to do it in a screensharing call with me, you can email me and we can schedule it.
(In reply to Buovjaga from comment #28) > If you want to do it in a screensharing call with me, you can email me and > we can schedule it. Thank you that would be great! I'll email you.
Created attachment 186002 [details] Start-up trace from XCode Instruments Time Profiler - v7.5.2 A zip file with the trace folder.
Since I got my new laptop, Lenovo IdeaPad 5 Pro with AMD Ryzen 7 processor, I experience the same problems. In Windows 11 it lasts loading of a file in Libreoffice about half a minute. Whether this is done through the main screen or directly makes no difference in LibreOffice 7.5.3.2. The strange thing is that on my old laptop, a Lenovo IdeaPad 5 with AMD Ryzen 5 processor, which also has LibreOffice version 7.5.3.2 installed, this problem does not occur. The various suggestions that are made to disable the proxy or install another version have no effect. What does work is turning off the internet connection, Libreoffice start up, load file and then turn on the internet connection again. It seems that during loading a file a control is started on the Internet. Switching on and off theInternet connection is of course not a real solution. What gives some improvement is to start Libreoffice when loading Windows, then there is only a delay when loading the first file. LibreOffice is the default application for office files. When loading Microsoft Office office files there is no delay.
John, please don't change the "version" field to a more recent one as it is supposed to be the earliest version affected. I'm setting the OS back to "macOS" and the status to "unconfirmed" until bunkem can confirm that the issue is indeed linked to being connected to the Internet. If not, John will have to open a separate report. Thank you!
Hi Stéphane and John. I'm not quite sure how to test this on the Mac as there isn't a switch to turn off networking except for WIFI and Bluetooth. So I just unplugged my ethernet connection with WIFI and Bluetooth off. It actually took longer to start-up LO than with the network connected. I think you've got to add a new bug report John. There is one thing in Windows that isn't in Mac. There is LO quick start program that can be enabled to start up when you turn on your computer. It doesn't exist on Mac. Perhaps this is running and so your startup is faster??
Hi all, I used to use Calc a lot, but all of a sudden startup of both Calc and Writer is taking so slow (over 20 seconds) that I'm actually avoiding to use them. It's equally sluggish whether I try to open a file per double click or if I simply start the program from the menu: The splash screen appears right away but the loading bar is stuck halfway for a long time before the program opens. From there on, everything is working perfectly. Version output: Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 12; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (en_US.utf8); UI: en-US 7.4.7-4 Calc: threaded Unfortunately I cannot say which updated caused this issue for me, but it's possible that it's occurring since I'm using Linux kernel 6.1, this one: 6.1.38-1-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Jul 5 23:49:30 UTC 2023 x86_64 GNU/Linux
(hent, let's try and stick to macOS for this bug report for now. Ideally, you'd test older versions obtained from https://downloadarchive.documentfoundation.org/libreoffice/old/ to see if it started with a specific LO release, or if it is indeed related to your kernel version. You can report your issue in a new ticket.) bunkem, did you manage to chat with buovjaga and try again a bibisect?
(In reply to Stéphane Guillou (stragu) from comment #36) > > bunkem, did you manage to chat with buovjaga and try again a bibisect? Hi Stéphane. Yes, I did speak with buovjaga. We worked together on it. If I remember correctly, I couldn't pin point the build that caused the slowdown. Please see post 30. We collected trace info about the slow start-ups.