Bug 48011 - LibreOffice 3.5 is unusably slow with large documents
Summary: LibreOffice 3.5 is unusably slow with large documents
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Caolán McNamara
Whiteboard: target:3.6.0 target:3.5.4
: 47712 (view as bug list)
Depends on:
Reported: 2012-03-28 13:27 UTC by Matt
Modified: 2013-12-04 12:03 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Test document (1.37 MB, application/vnd.oasis.opendocument.text)
2012-04-10 17:40 UTC, Matt

Note You need to log in before you can comment on or make changes to this bug.
Description Matt 2012-03-28 13:27:08 UTC
I have a large (1100 page) document that I've been editing with OO.org and LO for six years without any particular problems, but LO 3.5 has changed all that.

Editing any text takes an age. I can type a sentence and then site and watch as LO painstakingly puts each letter on the screen for me. I was following the LO PPA in Ubuntu 11.10, but had to remove it when 3.5 was released. I've retested with the latest LO 3.5.1 in Ubuntu 12.04 and it's no better.

Comment 1 Matt 2012-03-28 13:28:26 UTC
I meant "sit and watch", rather than site...
Comment 2 Petr Mladek 2012-04-05 01:10:20 UTC
I add some developers into CC. They might have some idea what has been changed in LO-3.5 and could cause this.

I wonder if you have installed the LanguageTool extensions and if it helps to disable spell check.

Just by chance, could you please attach a document that shows the problem? It would help us a lot with debugging.

I am sure that we will do our best to find and fix the significant performance problem. On the other hand, such a huge document is not typical => this bug should not block release of other useful bugfixes => lowering the severity a bit.
Comment 3 Caolán McNamara 2012-04-05 05:12:47 UTC
auto word-count-update maybe ?
Comment 4 Matt 2012-04-10 16:09:45 UTC
Personally I'm not entirely satisfied that such a huge decrease in performance (even for large documents) would be considered acceptable. As I say, it's fine in 3.4 and has been fine in many versions prior to that. This simply makes upgrade to 3.5 impossible for me.

It may be the auto word count feature, but it's impossible to test that hypothesis because there is no way to turn that off.  I never use the word count feature, so to me that's utterly useless and I would far rather that it wasn't wasting my time.

Failure to address this issue will mean that I will have a choice to make between moving the whole document to another system, or keeping LO3.4 for as long as possible (and then, presumably, moving to another system anyway).  Neither option fills me with great joy.
Comment 5 Caolán McNamara 2012-04-10 16:27:38 UTC
nobody claims its acceptable to be super-slow, its a matter of identifying the specific change that has triggered it. Which is a bit tricky as we don't have an easy to reproduce route for this. If you could attach your document here and give a how-to-reproduce that'd be helpful.

The word-count was just a guess, looking at that code the count per paragraph is cached so if a paragraph doesn't change the cost should be minimal, i.e. only the currently being edited paragraph would be recounted, which shouldn't be too bad
Comment 6 Matt 2012-04-10 17:39:41 UTC
Sorry, I can't attach the document as it's a client software requirements document.

I have played around with a large text downloaded from Project Gutenberg and found that LO3.4 and LO3.5 were fairly comparable on plain text. However, the document that I'm having problems with contains a lot of tables. Introducing some large tables into the PG document demonstrated my problem successfully: it was very slow to add text in a cell in LO3.5, and pretty much the same as adding to a normal paragraph in LO3.4.

I'll attach the document with the added tables.
Comment 7 Matt 2012-04-10 17:40:38 UTC
Created attachment 59783 [details]
Test document

Large document for testing speed of adding text to table cells in LO3.4 and LO3.5
Comment 8 Matt 2012-04-11 15:36:11 UTC (in Ubuntu 12.04 Precise) shows a marked improvement for the test document, but not for my actual document.
Comment 9 Caolán McNamara 2012-04-14 04:57:29 UTC
The grammar checker might be a factor in this (could be a few issue at play, rather than just one), e.g. turning off autospellcheck (which chains to the grammar checker) might make an impact.

Agreed that this is incredibly slow in a debugging build, but I need to reconfirm in a non-debugging build and try and bisect from a known good state
Comment 10 Rainer Bielefeld Retired 2012-04-16 10:48:04 UTC
NOT reproducible with reporter's attached sample and "LibreOffice 3.5.0 RC2 English UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit)

Seems to be LINUX only.
Comment 11 cekilch 2012-04-16 13:33:57 UTC
Problem IS reproducible with LO - Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f - (and 3.5.1) on Win XP 32 bit and several linux distributions (Ubuntu, Mint, Mageia) whereas attached sample document behaves fine with OOo 3.3 and LO 3.3. and 3.4.
Furthermore bug 47712 - https://bugs.freedesktop.org/show_bug.cgi?id=47712 - seems to describe the same problem as this bug report.
Comment 12 cekilch 2012-04-17 00:08:17 UTC
Just one more idea about the changes between 3.4 and 3.5: LO 3.4 wasn't usable for me because of the painstakingly slow behaviour of Writer when working with recorded changes (accept, deny them). This is back to normal "working speed" in LO 3.5 but now Writer seems to freeze (or overheat as the mentioned problems are always accompanied by hight cpu usage) when editing large documents.
(Last really working version of LO was 3.3. - that's why I'm now using OOo 3.3 - sad but true.)
Comment 13 Caolán McNamara 2012-04-18 06:02:34 UTC
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=7ed7df6ba854a799e8e9fb92c68650cc5e6e5695 will hopefully help a little anyway. Its not the full fix yet, just part of it.
Comment 14 Not Assigned 2012-04-24 04:16:21 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":


Resolves: fdo#48011 writer idle-callbacks are halting when events pending
Comment 15 Caolán McNamara 2012-04-24 04:22:06 UTC
Here's the scenario I can see and can fix....

a) load sample document in gnome
b) as soon as the UI lets you, open a new document and hold down "m"

as the new page fills up with "m"'s while the old document is being spell-checked, word-counted etc there's a perceptible lag every now and then, which will eventually, around the time the "m"'s fill half the page turn into a 6 second mega-lag

as far as I can see the new gtk-plug AnyInput (which is used by writer to detect user activity in order to halt the idle-time callback and return to the user) is the regression here
Comment 16 Not Assigned 2012-04-24 10:06:12 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":


Resolves: fdo#48011 writer idle-callbacks are halting when events pending

It will be available in LibreOffice 3.5.4.
Comment 17 Matt 2012-04-26 15:28:44 UTC
Thanks for all the effort that you've put into this. I will wait for packages to test on as I've been unsuccessful in building a working install.
Comment 18 Sulphur 2012-05-26 13:08:03 UTC
I also had this problem with big files in Ubuntu 12.04. I just tested Libreoffice via the Ubuntu PPA and it now works just great. Thanks!
Comment 19 Matt 2012-05-27 16:43:29 UTC
I tested on 3.5.4 RC1 and didn't see any particular improvement, so I converted my document to a master document with one document per-chapter so that I could safely move on.

I've just tested it with 3.5.4 RC2 and it the old document seems to work fine. Ah well, I'm sure that the master document approach will have some benefits anyway. Thanks again for working on this fix.
Comment 20 Sulphur 2012-05-30 09:41:55 UTC
Maybe I spoke too soon, or maybe I'm affected by something different, but after testing further I found that Writer is still freezing on me, though much less (still only huge documents, but I'm using ( on Ubuntu 12.04). 

Before it seemed to mostly freeze (UI totally unresponsive) for about 30 seconds when the auto spell checker kicked in (at least I thought that was it, as it wouldn't freeze right away when a document was opened with that option turned off) or, sometimes, when saving. 

It now doesn't freeze when it opens the files, which is nice, but if I save a file within, oh, 5 minutes of first opening it, everything still freezes. If I wait longer then it doesn't. Maybe there's still some problem with the auto spellcheck? None of this happened in versions before 3.5.
Comment 21 David 2012-06-02 06:36:22 UTC
This is NOT fixed in 3.5.4!  It is still unusably slow on large files when scrolling or selecting text.  I am now being forced to go to OpenOffice.org.  This is not the sort of regression that should be taking this long to fix.  It is too major of a problem.
Comment 22 David 2012-06-03 06:48:28 UTC
I did some more testing.  I purged all the LibreOffice installation files and removed the config directory under ~/.config.  I then re-installed only LibreOffice-Writer and the packages that it depends on.  It seemed to function normally after that.  Then I started to add packages but when either the libreoffice-sdbc-postgresql or the libreoffice-help-en-us packages were installed the problems started to re-occur and I needed to completely remove all the libreoffice packages again and re-install the libreoffice-writer package. 

I am using the ppa repository (http://ppa.launchpad.net/libreoffice/ppa/ubuntu) and kubuntu 12.04.
Comment 23 David 2012-06-03 07:15:46 UTC
Well it worked that way for a while then something got triggered again evidently and now it is back to being real sluggish.  I'm not sure what is triggering it.
Comment 24 David 2012-06-03 07:42:13 UTC
This file should be sufficient to use for testing this behavior: https://docs.google.com/uc?id=0BwXtYasxx291YjhjZDdkZWUtMTA1MC00YWQ4LTgzZjUtMDQyOTk5YzNlNGQy&export=download&hl=en

Download it and open it in editing mode.  Opening it for viewing only does not seem to exhibit the problem.
Comment 25 Caolán McNamara 2012-06-05 01:56:55 UTC
If you have a bug that looks superficially like another bug, don't reopen the original bug. File a new one. Especially in the case of performance bugs there are often multiple problems that give effectively the same result. And it makes it unmanageable if they all get lumped in together :-(

The problem fixed under this bug id was a gtk-specific one. e.g. a super slowdown under gtk, but kde (and/or windows, MacOSX) was ok. That aspect is definitely fixed anyway.

Its possible that your additional problem is a duplicate of fdo#48932, which I'm still hoping to get a review on to backport to 3-5. That one would be triggered by having lots of pages with header/footers or hard page breaks where drawing the page break and header/footer indicators is super slow.
Comment 26 Rainer Bielefeld Retired 2012-06-17 06:36:47 UTC
*** Bug 47712 has been marked as a duplicate of this bug. ***