Created attachment 116362 [details]
large file test
The master verstion of LibreOffice 5.1 alpha dated 2015-05-25 loads the attached document in about six seconds on my quad-core 3Ghz computer. The next master version, dated 2015-05-28, takes over 6 minutes. The latest version still exhibits this extreme slow down. I have a document that has gone from about a minute to over 30 minutes to load and like an hour or so to save.
Yep, 6 mins is about right.
Lowering severity as we don't use "blocker".
Win 7 Pro 64-bit Version: 220.127.116.11.alpha1+
Build ID: 698b344fdf42cc9738d5e91cd27876ce1ff39daf
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-10_02:24:19
Locale: fi-FI (fi_FI)
On a newly compiled master of 5.1, the attached file is now taking over 1.5 hours to load. It's gone from 6 seconds to 6 minutes to now 90 minutes.
Using the master dbgutil bibisect repo, I get 290-300s loading the attached file with 2015-05-25, 26, 27, 28 and 08-20
I'm going to go out on a limb and suggest that the problem here is not comparing like with like? There will be large differences in performance between regular / debug / dbgutil builds.
Taking bibisectRequest off for now as there doesn't seem to be anything to see using bibisect, but if the above is the case then this should be RESOLVED NOTABUG
I'm using only the regular version, and the load/save times have gotten very extreme from previous versions.
Bisected the hard way with a non-debug build and came up with the below commit - before it, loading the file takes 3 seconds, after 130s continuing up to the present (4385e2d3c42b54390cb27546f7fa1a19fca8e8c5)
Adding Cc: to email@example.com; Could you possibly take a look at this one? Thanks
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Sat May 23 13:25:12 2015 +0200
remove the weak_ptrs on destruction too
I seem to have libreoffice 5.0.1 installed here, I have a 64 bit linux on dual core intel celeron processor.
The problem is that saving a file is 30 seconds or more, and loading takes about an hour or more for a text file having around 2mb.
Loading also takes long (but didn't wait for it to finish) for the odt file made from the above mentioned text file, and this odt has 1.1m
This should be fixed with:
This issue is not fixed. In the first comment, loading the attached document took over 6 minutes when with version 5.0.x it takes about 6 seconds. Then in comment 3, with a later build, the load time took about 90 minutes. With a master compiled on 12/04, loading the attached has taken over 2 hours and I finally killed the process. So instead of being fixed, the regression has gotten even worse. Did anybody actually try to load the attached document before declaring this issue fixed?
(In reply to David from comment #8)
> This issue is not fixed. In the first comment, loading the attached
> document took over 6 minutes when with version 5.0.x it takes about 6
> seconds. Then in comment 3, with a later build, the load time took about 90
> minutes. With a master compiled on 12/04, loading the attached has taken
> over 2 hours and I finally killed the process. So instead of being fixed,
> the regression has gotten even worse. Did anybody actually try to load the
> attached document before declaring this issue fixed?
ehh.. it loads in like 5 seconds for me.
Win 7 Pro 64-bit Version: 18.104.22.168.alpha0+
Build ID: 81fa5340191baf8687f9c82f1f414f5afc86b529
Threads 4; Ver: Windows 6.1; Render: default;
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-03_21:19:19
Locale: fi-FI (fi_FI)
Is this a Linux only problem? I'm running Debian Jessie on a quad-core 3Ghz computer, and when I try loading the file, one core is running at 100% for as long as I leave it sit there.
I tried the pre-compiled version from the daily/master archive and it does seem to work just fine now. I don't know why it's not loading with my own compiled version, but it looks like the not loading issue is a separate problem from what was before occurring. So I'm going to re-close this bug since it does seem to be fixed. Sorry for re-opening it.
(note that the performance issue you see might be caused by extensions or settings in the profile of your installation, if you use different ones.
Migrating Whiteboard tags to Keywords: (bibisected, perf)