libreoffice-calc very slow to open/save documents with large cell contents

Bug #1034999 reported by Steve Magoun on 2012-08-09
This bug affects 11 people
Affects Status Importance Assigned to Milestone
libreoffice (Ubuntu)

Bug Description

Libreoffice-calc 3.6 takes a long time (30sec to minutes) to open/save spreadsheets containing cells with a lot of content. This is a regression from libreoffice 3.5 in 12.04 (tested with 1:3.5.4-0ubuntu1)

To reproduce:
1) Open the attached spreadsheet, which contains 1 cell with ~4k characters in it

Expected results:
Spreadsheet opens quickly (<2sec on my 2.4Ghz Core2Duo w/ SSD)

Actual results:
Libreoffice splash screen shows, libreoffice window is displayed as a gray rectangle with no content, and libreoffice window then becomes unresponsive. CPU usage is at 100% on one core. The system stays in this state for ~30sec. The document eventually opens and libreoffice functions normally.

Saving documents with lots of data in a cell takes just as long as opening/reading those documents, with similar symptoms - libreoffice becomes unresponsive, one CPU core is at full utilization, etc.

The amount of text in the cell is directly correlated to the length of time required to open/save the doc.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libreoffice-calc 1:3.6.0~rc4-0ubuntu2
ProcVersionSignature: Ubuntu 3.5.0-8.8-generic 3.5.0
Uname: Linux 3.5.0-8-generic x86_64
ApportVersion: 2.4-0ubuntu6
Architecture: amd64
Date: Thu Aug 9 13:20:27 2012
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta amd64 (20100901.1)
 PATH=(custom, user)
SourcePackage: libreoffice
UpgradeStatus: Upgraded to quantal on 2012-08-07 (2 days ago)

Steve Magoun (smagoun) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Steve Magoun (smagoun) wrote :
Download full text (5.7 KiB)

This might be limited to .ods files - .xlsx files with the same content do not suffer the problem. A quick check of the soffice.bin shows that .ods import is spending all its time in XML_ParseBuffer() and its children. Sample stack trace:

(gdb) bt
#0 0x00007f8c7044868a in ?? ()
   from /usr/lib/libreoffice/program/../program/
#1 0x00007f8c70449d33 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#2 0x00007f8c70457c74 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#3 0x00007f8c704583cc in ?? ()
   from /usr/lib/libreoffice/program/../program/
#4 0x00007f8c7045c2f4 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#5 0x00007f8c7041877c in EditEngine::SetUpdateMode(unsigned char) ()
   from /usr/lib/libreoffice/program/../program/
#6 0x00007f8c71481187 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#7 0x00007f8c70503ba9 in SvxUnoTextCursor::gotoRange(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&, unsigned char) ()
   from /usr/lib/libreoffice/program/../program/
#8 0x00007f8c72734f12 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#9 0x00007f8c727366d9 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#10 0x00007f8c72533fe3 in SvXMLImport::endElement(rtl::OUString const&) ()
   from /usr/lib/libreoffice/program/../program/
---Type <return> to continue, or q <return> to quit---
#11 0x00007f8c721f236d in ?? ()
   from /usr/lib/libreoffice/program/../program/
#12 0x00007f8c92714454 in ?? () from /lib/x86_64-linux-gnu/
#13 0x00007f8c9271554e in ?? () from /lib/x86_64-linux-gnu/
#14 0x00007f8c9271985d in XML_ParseBuffer ()
   from /lib/x86_64-linux-gnu/
#15 0x00007f8c721f0c16 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#16 0x00007f8c721f49ee in ?? ()
   from /usr/lib/libreoffice/program/../program/
#17 0x00007f8c711d8c9d in ?? ()
   from /usr/lib/libreoffice/program/../program/
#18 0x00007f8c711dac87 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#19 0x00007f8c7129f502 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#20 0x00007f8c7129f8bd in ScDocShell::Load(SfxMedium&) ()
   from /usr/lib/libreoffice/program/../program/
#21 0x00007f8c9ac53d0d in SfxObjectShell::LoadOwnFormat(SfxMedium&) ()
   from /usr/lib/libreoffice/program/
#22 0x00007f8c9ac60c45 in SfxObjectShell::DoLoad(SfxMedium*) ()
   from /usr/lib/libreoffice/program/
#23 0x00007f8c9aca3d8d in SfxBaseModel::load(com::sun::star::uno::Sequence<com::---Type <return> to continue, or q <return> to quit---
sun::star::beans::PropertyValue> const&) ()
   from /usr/lib/libreoffice/program/
#24 0x00007f8c9acdd520 in ?? () from /usr/lib/libreoffice/program/
#25 0x00007f8c7afc76b3 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#26 0x00007f8c7afc8af8 in ?? ()
   from /usr/lib/libreoffice/program/../program/
#27 0x00007f8c7af4134e in ?? ()


Joschi Poschi (joschiposchi) wrote :

Still present in Libreoffice 4.0 in Quantal with all the latest updates. Gnumeric in comparison is blazing fast with this task.

Steve Magoun, thank you for reporting this and helping make Ubuntu better. This is unreproducible in Xubuntu. Could you please test for this in Raring via and/or Saucy via and report the results?

lsb_release -rd
Description: Ubuntu 13.04
Release: 13.04

apt-cache policy libreoffice-writer
  Installed: 1:4.0.2-0ubuntu1
  Candidate: 1:4.0.2-0ubuntu1
  Version table:
 *** 1:4.0.2-0ubuntu1 0
        500 raring/main i386 Packages
        100 /var/lib/dpkg/status

Changed in libreoffice (Ubuntu):
status: Confirmed → Incomplete
Steve Magoun (smagoun) wrote :

This is reproducible in raring (13.04) with libreoffice 1:4.0.2-0ubuntu1. I used the sample document attached to this bug.

Changed in libreoffice (Ubuntu):
status: Incomplete → Confirmed
Mihai Dontu (mihai-dontu) wrote :

I have the same issue with an XLSX document of ~900K (uncompressed: ~14M), which is opened in ~5min. I have attached the output of 'perf top -K -p <soffice.bin-pid>'. M$'s Excel opens it in ~5s.

Mihai Dontu, please file a new report and feel free to subscribe me to it:
ubuntu-bug libreoffice-calc

tags: added: regression-release
Ivan Williams (ivan-volkspares) wrote :

I can confirm this bug:

Acer emachine E730G
Win7 Home Premium SP1
Core i3 CPU
4Gig ram
ATI Readon HD5470

File size 360kb
Calc .ods filetype
Tabs (5)
Max rows per tab 8849
Max Columns per tab 8
No formulas (flat data)
Some fomatting, cell colour etc.

Time to save 65 seconds!!

2 CPU cores maintan approx 50%

Francewhoa (francewhoa) wrote :

Confirming this issue, using:
* LibreOffice version 4.1.4, 64 bits
* Kernel Linux 3.2.0-4-amd64
* GNOME 3.4.2

Francewhoa (francewhoa) wrote :

I found a temporary workaround that improved the performance from 40 seconds to 1 second or less in my case, read more at

madbiologist (me-again) wrote :

Does this still occur on Ubuntu 14.04 "Trusty Tahr" with Libreoffice ? Calc had a lot of performance improvements in Libreoffice 4.2 - see

The currently under development Ubuntu 14.10 "Utopic Unicorn" has the recently released Libreoffice 4.3.

Changed in libreoffice (Ubuntu):
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for libreoffice (Ubuntu) because there has been no activity for 60 days.]

Changed in libreoffice (Ubuntu):
status: Incomplete → Expired
Francewhoa (francewhoa) on 2017-06-15
Changed in libreoffice (Ubuntu):
status: Expired → Confirmed
Francewhoa (francewhoa) wrote :

Confirming this bug is still present with latest LibreOffice stable version

The amount of text in the cell is directly correlated to the length of time required to open or edit the cell.

Steps to reproduce:
1. Install fresh LibreOffice
2. Create a fresh calc spreadsheet
3. Paste into a cell any text with the following minimum values:
...• Lines: 500
...• Words: 4,000
...• Calculations: None
...• Formatting on cell: None

4. LibreOffice hang. After a few minutes the text is pasted.
5. Double click on that cell to open it. LibreOffice hang again. And so on.

• LibreOffice version:
• LibreOffice build ID: 1:5.2.7-1~bpo8+1
• LibreOffice CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: gtk3;
• LibreOffice Locale: en-CA (en_CA.utf8); Calc: group
• 32GB ram
• Java 1.8.0_131 Oracle Corporation
• Gnome: 3.14.1
• Kernel: 4.9.0-0.bpo.3-amd64 #1 SMP Debian 4.9.25-1~bpo8+1 (2017-05-19) x86_64 GNU/Linux
• Base: Debian 8.8 Jessie, 64-bit

Francewhoa (francewhoa) wrote :

I created a bug report using the official LibreOffice ticketing system at

Feel really free to use either ticketing systems

If you are able to reproduce that bug, to speed up a fix, I suggest for all to post a comment to the LibreOffice ticketing system. To let them know this bug is confirmed.

Any volunteers for a patch? I would be happy to contribute testing and documentation if needed. Again, to get a faster response I suggest to reply at

madbiologist (me-again) wrote :

I can't reproduce this with LibreOffice on Ubuntu 17.04 64 bit using the file attached to comment #1

Francewhoa (francewhoa) wrote :

Thanks for your testing madbiologist :) Same here I can not reproduce with the file attached in comment #1 above and LibreOffice

I'll post another comment shortly with another file. Which both me and Telestro were able to reproduce with.

Francewhoa (francewhoa) wrote :

Here are more test results with LibreOffice (LO) using the attached file "lorem_ipsum---Francewhoa---2017-06-15.txt"

• With LO 4.2 Francewhoa was NOT able to reproduce
• With LO Telesto was NOT able to reproduce
• With LO Telesto was ABLE to reproduce
• With LO Francewhoa was ABLE to reproduce
• With LO Telesto was ABLE to reproduce

So it seems something was introduce between and Which in turn cause the slow performance.

The main difference between the files attached in comment #1 above and the file attached to this comment #18 is their length. 129 lines compare to 235 lines. So somehow the lag is triggered when the cell content is between 130 and 235 lines.

Telesto's test results are in comment #4 at

Francewhoa (francewhoa) wrote :

To narrow down the source(s) of the issue I further tested. Confirming the lag is both correlated with the number of lines and exponential with the number of lines. With these latest tests the lag per action ranges from ~2 seconds with 129 lines to more than 13+ minutes lag with 940+ lines, and so on and exponential.

Test results and steps to reproduce in comment 12 at

madbiologist (me-again) wrote :

I can reproduce this on LibreOffice with the file from comment 18 when I paste the contents of that file into a single cell. In fact the first time I attempted to paste, calc crashed and then it's document recovery dialog appeared. The paste worked on the second attempt, but was very slow. Attempting to edit the text in the cell was also very slow.

However this doesn't seem like a common use case for a spreadsheet. I would expect that text like this was stored and edited in a writer document. Do you mind if I ask why you want to put this large amount of text into a spreadsheet cell?

madbiologist (me-again) wrote :

Oops, I comment #20 should say that I tested with LibreOffice

Olivier Tilloy (osomon) wrote :

Confirmed that this is still happening with libreoffice 5.3.3-0ubuntu1 on artful.
Pasting the text from comment #18 in a single cell takes 30 seconds on my machine.

@madbiologist: the commonality of that use case is not really the point (although it might influence the importance of the bug report). People use spreadsheets in lots of creative ways and it should never take that long to paste some text, regardless of its size (the sample text in comment #18 is only 11604 words, it's not even that big).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.