Bug 91925 - Large files load & save extremely slow
Summary: Large files load & save extremely slow
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks:
 
Reported: 2015-06-07 23:56 UTC by David
Modified: 2018-07-07 14:21 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
large file test (1.56 MB, application/vnd.oasis.opendocument.text)
2015-06-07 23:56 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2015-06-07 23:56:19 UTC
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.
Comment 1 Buovjaga 2015-06-10 18:15:58 UTC
Yep, 6 mins is about right.

Lowering severity as we don't use "blocker".

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 698b344fdf42cc9738d5e91cd27876ce1ff39daf
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-10_02:24:19
Locale: fi-FI (fi_FI)
Comment 2 David 2015-07-26 13:32:05 UTC
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.
Comment 3 Matthew Francis 2015-08-20 05:10:28 UTC
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
Comment 4 David 2015-08-20 13:12:39 UTC
I'm using only the regular version, and the load/save times have gotten very extreme from previous versions.
Comment 5 Matthew Francis 2015-08-21 13:15:40 UTC
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 bjoern.michaelsen@canonical.com; Could you possibly take a look at this one? Thanks

commit 692c886f937c525d6bfcb541917a5114b085efa9
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sat May 23 13:25:12 2015 +0200

    remove the weak_ptrs on destruction too
    
    Change-Id: I65f5867c41417539a70eef15754988d9931394a4
Comment 6 Michał Zegan 2015-09-12 16:39:41 UTC
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
Comment 7 Björn Michaelsen 2015-11-29 01:15:56 UTC
This should be fixed with:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f99e8f84f5421076b6c0c10a592e43843eabd8ff
Comment 8 David 2015-12-05 00:14:22 UTC
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?
Comment 9 Buovjaga 2015-12-05 11:38:18 UTC
(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: 5.2.0.0.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)
Comment 10 David 2015-12-05 13:25:54 UTC
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.
Comment 11 David 2015-12-05 14:18:46 UTC
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.
Comment 12 Björn Michaelsen 2015-12-06 20:09:37 UTC
(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.
Comment 13 Robinson Tryon (qubit) 2015-12-09 17:52:43 UTC
Migrating Whiteboard tags to Keywords: (bibisected, perf)