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

[Steve Magoun]

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)
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: Upgraded to quantal on 2012-08-07 (2 days ago)

[Launchpad Janitor (janitor)]

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

[Steve Magoun (smagoun)]

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

[Joschi Poschi (joschiposchi)]

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

[penalvch (penalvch)]

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 http://releases.ubuntu.com/raring/ and/or Saucy via http://cdimage.ubuntu.com/daily-live/current/ and report the results?

lsb_release -rd
Description: Ubuntu 13.04
Release: 13.04

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

[Steve Magoun (smagoun)]

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

[Mihai Dontu (mihai-dontu)]

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.

[penalvch (penalvch)]

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

[Ivan Williams (ivan-volkspares)]

I can confirm this bug:

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

File size 360kb
LibreOffice 4.1.1.2
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)]

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

[Francewhoa (francewhoa)]

I found a temporary workaround that improved the performance from 40 seconds to 1 second or less in my case, read more at http://ask.libreoffice.org/en/question/32972/why-the-super-slow-saves-in-calc/?answer=34636#post-id-34636

[madbiologist (me-again)]

Does this still occur on Ubuntu 14.04 "Trusty Tahr" with Libreoffice 4.2.6.3-0ubuntu1 ? Calc had a lot of performance improvements in Libreoffice 4.2 - see https://wiki.documentfoundation.org/ReleaseNotes/4.2#Performance

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

[Launchpad Janitor (janitor)]

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

[Francewhoa (francewhoa)]

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.

Using:
• LibreOffice version: 5.2.7.2
• 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+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134057
calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods

Hi LibreOffice enthusiasts :)

Challenge summary:
Using LibreOffice (LO) Calc, adding large amount of text to a text cell result in Calc hangs. Hang ranges from slow to unusable Calc. Same challenge with opening large cells.

Steps to reproduce challenge:
1. Install fresh LibreOffice 5.2.7.2

2. Create a fresh Calc spreadsheet. Find attached spreadsheet titled "calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods"

3. Paste into a cell any text with the following minimum values:
...• Lines: 235
...• Words: 11,604
...• Characters with space: 78,936
...• Calculations: None
...• Formatting on cell: No advanced formatting
For spreadsheet example, find attached file titled "calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods"

4. LibreOffice hang for ~30 seconds. One CPU is running at 100%. After that hang the text is pasted.

5. Double click on that cell to open it. LibreOffice hangs again for another ~30 seconds. And so on.

The amount of text in the cell is directly correlated to the length of time required to open or edit the cell. So 470 lines is roughly double the hang time than 235 lines.

Expected outcome:
• Expected result is the text should be added to the text cell within ~1 second. Not ~30 seconds. 30 seconds is very fast if we need to do one operation within ~one day. But the issue is that we need to do multiple operations within 1 minute. Then we need to do that multiple time per day, week, year. For example when we need to do 10 to 20 copy-paste operations per minute, the total freeze time range from 5 to 10 minutes. Which is too slow. Another example is with 100 to 200 copy-paste, which result in a total freeze ranges 50 to 100 minutes. Again too slow. There is something slowing down both the copy-paste process of a large cell and opening a large cell. It's unclear what is causing that.

What we tried that was effective:
• Use LibreOffice 4.2. Instead of 5.2.7.2. This issue can not be reproduce on LibreOffice 4.2.
• Using 5.2.7.2, brake down the large cell content into multiple small cells. But that's not usable, as I need to add large amount of text to large amount of cells, and sheets.

What I tried that was ineffective:
• "Format" menu > "Cell" option > "Numbers" > Text
• "Format" menu > "Clear Direct Formatting" option
• Increase memory at “Tools > LibreOffice > Memory“
• Force LO to use the lastest installed Java 1.8 at “Tools > Options > LibreOffice > Advanced > Expert Configuration”
• Close the LO sidebar
• "Format" menu > "Cell" option > "Alignment" > unchecked "Wrap text automatically"

Suggested fix:
• Allow users to add large amount of text without triggering whatever is triggering intensive CPU usage. Assuming the user is adding simple text and without complex formatting and without any calculation. No cell validation is requested, but maybe somehow LO is trying to validate the full content of the cell. If so, how about allowing the user to deactivate such automated validation per cell, per sheet, per spreadsheet, per LO global setting?

LibreOffice:
• Ver...

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134058
calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134059
lorem_ipsum---Francewhoa---2017-06-15.txt

Text used to reproduce this challenge

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134060
screenshot---About_LibreOffice---Francewhoa---2017-06-15.jpg

[Francewhoa (francewhoa)]

I created a bug report using the official LibreOffice ticketing system at https://bugs.documentfoundation.org/show_bug.cgi?id=108560

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 https://bugs.documentfoundation.org/show_bug.cgi?id=108560

[Telesto (telesto)]

I do notice quite some lag with:
Version: 6.0.0.0.alpha0+
Build ID: cbf371e07fd5dea1ea08a1f299360d1273961ebd
CPU threads: 4; OS: Windows 6.19; UI render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2017-06-14_23:13:57
Locale: nl-NL (nl_NL); Calc: CL

and with
Version: 5.0.6.3
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa-GL
Locale: en-US (nl_NL)

but not with
Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: nl-NL (nl_NL)

[madbiologist (me-again)]

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

[Francewhoa (francewhoa)]

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

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

[Francewhoa (francewhoa)]

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 5.0.0.5 Telesto was NOT able to reproduce
• With LO 5.0.6.3 Telesto was ABLE to reproduce
• With LO 5.2.7.2 Francewhoa was ABLE to reproduce
• With LO 6.0.0.0.alpha0+ Telesto was ABLE to reproduce

So it seems something was introduce between 5.0.0.5 and 5.0.6.3. 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 https://bugs.documentfoundation.org/show_bug.cgi?id=108560#c4

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134084
Dependencies.txt

Shorter text file for testing. With 130 lines. Thanks to smagoun :)

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

The main difference between the files attached in comment #5 and #2 above are their length. 129 lines compare to 235 lines. So somehow the lag is triggered when the cell content is between line 130 and 235.

Here is a summary of the test results with LibreOffice (LO) using file in #2 for the cell content

• With LO 4.2 Francewhoa was NOT able to reproduce
• With LO 5.0.0.5 Telesto was NOT able to reproduce
• With LO 5.0.6.3 Telesto was ABLE to reproduce
• With LO 5.2.7.2 Francewhoa was ABLE to reproduce
• With LO 6.0.0.0.alpha0+ Telesto was ABLE to reproduce

So it seems something was introduce between 5.0.0.5 and 5.0.6.3

#5 result in a small lag. Just ~2 seconds per operation. So Calc is still usable if the cell is below 129 lines. But conditional to the user having a fast CPU. Intel Core i7 at 3.10 GHz with 8 CPUs.

#2 result in a much bigger lag. ~30 seconds per operation. So Calc is not usable. Notice that roughly double the number of cell lines result in 15 times more lag. So the lag is both directly correlated to the number of lines in the cell, and the lag is also exponential. Ho Ho :O. In other words, the lag increase rapidly with additional lines in the cell.

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

I'll post shortly 4 new files which I used to further narrow down the source(s) of the issue

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134088
lorem_ipsum---129_lines---773_characters---Francewhoa---2017-06-17.txt

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134089
lorem_ipsum---235_lines---1409_characters---Francewhoa---2017-06-17.txt

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134090
lorem_ipsum---470_lines---2819_characters---Francewhoa---2017-06-17.txt

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 134091
lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Test results:
• File in comment #8 is 129 lines, 773 characters with spaces, 0.7 kB size.
  Results in ~2 seconds lag per action. Calc IS usable :)

• File in comment #9 is 235 lines, 1,409 characters with spaces, 1.4 kB size.
  Results in ~11 seconds lag per action. Calc is NOT usable :(

• File in comment #10 is 470 lines, 2,819 characters with spaces, 2.8 kB size.
  Results in ~100 seconds lag per action. Calc is NOT usable :(

• File in comment #11 is 940 lines, 5,639 characters with spaces, 5.6 kB size.
  Results in ~780 seconds lag per action. Calc is NOT usable :(

The lag is both correlated with the number of lines and exponential with the number of lines. In other words, 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.

Notice that the results above are sorted top down in lag time results. The last result in comment #11 is ~780 seconds lag which means ~13 minutes lag. That is longggggg for just one action with simple text without calculation and minimum formatting. So long I could feel my beard growing and I needed a second shave after the lag, LOL (joke ;) Also during that long lag period all LibreOffice tools are frozen and not usable. So the users can not use Calc, Write, or any other LibreOffice tool. In my personal experience, after 5 to 10 seconds lag most users feel the software crashed, froze, or is not working, most user don't know it is a lag.

All those tests are using LibreOffice 5.2.7.2. Steps to reproduce and details in this ticket description above.

While testing, another thing I noticed is during the lag one CPU is used at 100%. If the computer as multiple CPUs, for example 8 CPUs, then each CPU is used in turn at 100%. Roughly 2 to 3 seconds each at 100%. So one CPU always at 100%. That means users with fast CPU at 3+ GHz and 8+ CPU might not notice the ~2 seconds lag with the file in comment #8 at 129 lines. But users with slower or less CPU(s) might face the challenge of having both their LibreOffice and their full computer not usable during a longer lag.

If you try to reproduce this lag, I suggest to double check that you do at least two actions on a large cell, not just one action. Because sometime when using a freshly open and blank Calc spreadsheet, the first action is very fast with a large cell. The lag is sometime triggered only with the second action with a large cell, and all following actions. By "action" I mean action on a large cell such as open, edit, or paste into.

[Francewhoa (francewhoa)]

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 https://bugs.documentfoundation.org/show_bug.cgi?id=108560#c12

[madbiologist (me-again)]

I can reproduce this on LibreOffice 5.2.7.2 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)]

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

[Olivier Tilloy (osomon)]

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).

[Telesto (telesto)]

Maybe a dupe of bug 84099 ?

[Ilmari-lauhakangas (ilmari-lauhakangas)]

(In reply to Telesto from comment #13)
> Maybe a dupe of bug 84099 ?

Nope, bug 84099 already appears with 4.2.0.

[Telesto (telesto)]

(In reply to Buovjaga from comment #14)
> (In reply to Telesto from comment #13)
> > Maybe a dupe of bug 84099 ?
>
> Nope, bug 84099 already appears with 4.2.0.

Second attempt: might be related to bug 108608

[Ilmari-lauhakangas (ilmari-lauhakangas)]

(In reply to Telesto from comment #15)
> Second attempt: might be related to bug 108608

That is Draw and this is Calc. Should do a callgrind on this, though...

[Ilmari-lauhakangas (ilmari-lauhakangas)]

Um, I don't get any slowness from pasting attachment 134059
Please test with a recent build.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: ef22c4a0a99be5d2903fb9e9d09fc852cd791173
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on January 12th 2018

[Telesto (telesto)]

(In reply to Buovjaga from comment #17)
> Um, I don't get any slowness from pasting attachment 134059 [details]
> Please test with a recent build.
>
I didn't check, but indeed. It's pretty decent:
Version: 6.1.0.0.alpha0+
Build ID: ef22c4a0a99be5d2903fb9e9d09fc852cd791173
CPU threads: 4; OS: Windows 6.3; UI render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2018-01-12_09:16:04
Locale: nl-NL (nl_NL); Calc: CL

However, it's still slow with OpenGL enabled

[Qa-admin-q (qa-admin-q)]

** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

[Jacques (1jacquez)]

Not yet fixed by Version: 6.3.3.2 even if OpenGl is unticked.
I have tried all the various proposed solutions posted in many different forums.

This is for relatively very simple spreadsheet, only text, no calculations.
A simple address list of only 1000 rows, but one cell has 1-3 paragraphs of text comments.

The problem affects not only the LibreOffice suite, but the entire computer. The mouse becomes like chewing gum and navigation of the entire systems becomes impossible. One has to wait, sometimes forever, and the system requires restart.

[Ilmari-lauhakangas (ilmari-lauhakangas)]

(In reply to Jacques from comment #20)
> Not yet fixed by Version: 6.3.3.2 even if OpenGl is unticked.
> I have tried all the various proposed solutions posted in many different
> forums.
>
> This is for relatively very simple spreadsheet, only text, no calculations.
> A simple address list of only 1000 rows, but one cell has 1-3 paragraphs of
> text comments.
>
> The problem affects not only the LibreOffice suite, but the entire computer.
> The mouse becomes like chewing gum and navigation of the entire systems
> becomes impossible. One has to wait, sometimes forever, and the system
> requires restart.

If you are talking about some other document than what are attached in this report, please open a new report.

As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it does not make sense to keep OpenGL UI reports open.

Details about Skia: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Comment on attachment 134059
lorem_ipsum---Francewhoa---2017-06-15.txt

@Francewhoa :) This is a note to myself. To facilitate future communications. I'm setting this file to "obsolete".

As this file titled "lorem_ipsum---Francewhoa---2017-06-15.txt" was cancel and replace by these newer files in:
• Comment 8
• Comment 9
• Comment 10
• Comment 11

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Comment on attachment 134084
Dependencies.txt

@Francewhoa :) This is a note to myself. To facilitate future communications. I'm setting this file to "obsolete".

As this file titled "Dependencies.txt" was cancel and replace by these newer files in:
• Comment 8
• Comment 9
• Comment 10
• Comment 11

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 167628
calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2020-11-27.ods

@Francois :) This is a note to myself. This new attached file titled
"calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2020-11-27.ods"
cancels and replace the previous file titled
"134057: calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods"

The only two differences are that the new file titled
"calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2020-11-27.ods":

1. Was created with LibreOffice 7
2. In cell A1, the content of the other file
"lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt"
was paste as is. Calc needed 14 minutes to process. Using the same hardware & resources as my 2017 comment above.

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Hello all LO enthusiasts :) I was able to reproduce this challenge again. I'll re-open it shortly with clarified steps to reproduce with LibreOffice 7.

Thanks all for your tests & contributions above. As for some of the comments above claiming that they were not able to reproduce this challenge. Maybe they used outdated test files attached to this ticket? Or maybe it was not clear which attached files were up to date and which ones were out dated? Anyhow, to facilitate future communications, today I cleaned up my attached files. So that only the up to date files are display, and the out dated files are hidden and tag as "obsolete".

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 167629
mockup---suggested_resolution---francewhoa---ksnip---2020-11-27_nov---v2.jpg

@Francewhoa :) Note to myself. This mockup shows my suggested resolution. I'll add another comment shortly to clarify this.

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Hello again all LO enthusiasts :) This is to confirm that this challenge is still present with the recent LO Calc version 7.0.3.1. And also with both versions 6.1.5 and 5.2.7. So I'm re-opening this ticket. Same challenge with OpenGL deactivated or activated.

I'm the original author of this ticket. I tried to edit my ticket "Description" but found no way to do this. Anybody know how to do this?
Meanwhile, this present comment 27 cancels and replaces my original ticket Description above. It is the same Description, but to facilitate collaboration, this new comment 27 is a clarified and updated Description of the challenge. I also clarified the ticket title to: "Pasting or editing multi-line cells ranges from slow to unusable Calc"

This challenge can be reproduce with 7.0.3.1, and 6.1.5, and 5.2.7. But could not be reproduce with 4.2.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

Challenge summary:

Using LibreOffice (LO) Calc, pasting large amount of multi-lines text into a cell result in Calc hangs. In turn, all other LO applications hang. This global hang ranges from seconds to minutes. This range depends mostly on the amount of multi-lines text, and your CPU. In turn, Calc and all LO application are unusable. Same challenge with editing cells with large amount of multi-lines text.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

Steps to reproduce challenge:

1. Using the following fresh installs:
______• LO:
____________• Version: 7.0.3.1
____________• Build ID: 00(Build:1)
____________• CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
____________• Locale: en-CA (en_CA.UTF-8); UI: en-US
____________• Debian package version: 1:7.0.3-3_bpo10+1
____________• Calc: threaded
____________• OpenGL: Deactivated or activated. Same result.
______• Debian:
____________• Version: 10. Buster. 64-bit.
____________• Gnome: 3.30.2 with Wayland
____________• Kernel: 5.8.0-0.bpo.2-amd64 #1 SMP Debian 5.8.10-1~bpo10+1 (2020-09-26) x86_64 GNU/Linux
______• Hardware:
____________• Ram: 31GB. Only LO is open and active.
____________• Processor: Intel Core i7 @ 3.10 GHz
____________• CPU: 8

2. Create a fresh Calc spreadsheet. Optionally, use the spreadsheet attached to this Comment 1 above. Spreadsheet is titled: "calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods"

3. Using any text editor to you liking, such as GEdit:

______3.1. Open the text file attached to Comment 12 above. This file is titled: "lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt"

______3.2. Copy all the text as is. Double check that your text editor does not make any formatting operations on this text without notifying you. Most importantly, the multi-lines text need to be kept as is. Not automatically reformatted on one line. If unsure about this, I suggest to use a very small and simple text editor. Such as GEdit.

5. Using LO Calc, using cell A1, double check that the cell is presently configured with Calc defaults. Including, but not limited to, no text formatting of any kind. Do not make any change to the cell.

6. Before you proceed with the next step below. Heads up that both ...

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Hello all :) I searched but found no way to edit my comment 27 above. Anybody know how to do this?

Meanwhile comment 27 is obsolete. I'll add my updated comment with the fixed typo to a new comment below.

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Hello again all LO enthusiasts :) This is to confirm that this challenge is still present with the recent LO Calc version 7.0.3.1. And also with both versions 6.1.5 and 5.2.7. So I'm re-opening this ticket. Same challenge with OpenGL deactivated or activated.

I'm the original author of this ticket. I tried to edit my ticket "Description" but found no way to do this. Anybody know how to do this?
Meanwhile, this present Comment 29 cancels and replaces my original ticket Description above. It is the same Description, but to facilitate collaboration, this new Comment 29 is a clarified and updated Description of the challenge. I also clarified the ticket title to: "Pasting or editing multi-line cells ranges from slow to unusable Calc"

This challenge can be reproduce with 7.0.3.1, and 6.1.5, and 5.2.7. But could not be reproduce with 4.2.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

Challenge summary:

Using LibreOffice (LO) Calc, pasting large amount of multi-lines text into a cell result in Calc hangs. In turn, all other LO applications hang. This global hang ranges from seconds to minutes. This range depends mostly on the amount of multi-lines text, and your CPU. In turn, Calc and all LO application are unusable. Same challenge with editing cells with large amount of multi-lines text.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

Steps to reproduce challenge:

1. Using the following fresh installs:
______• LO:
____________• Version: 7.0.3.1
____________• Build ID: 00(Build:1)
____________• CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
____________• Locale: en-CA (en_CA.UTF-8); UI: en-US
____________• Debian package version: 1:7.0.3-3_bpo10+1
____________• Calc: threaded
____________• OpenGL: Deactivated or activated. Same result.
______• Debian:
____________• Version: 10. Buster. 64-bit.
____________• Gnome: 3.30.2 with Wayland
____________• Kernel: 5.8.0-0.bpo.2-amd64 #1 SMP Debian 5.8.10-1~bpo10+1 (2020-09-26) x86_64 GNU/Linux
______• Hardware:
____________• Ram: 31GB. Only LO is open and active.
____________• Processor: Intel Core i7 @ 3.10 GHz
____________• CPU: 8

2. Create a fresh Calc spreadsheet. Optionally, use the spreadsheet attached to this Comment 1 above. Spreadsheet is titled: "calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods"

3. Using any text editor to you liking, such as GEdit:

______3.1. Open the text file attached to Comment 11 above. This file is titled: "lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt"

______3.2. Copy all the text as is. Double check that your text editor does not make any formatting operations on this text without notifying you. Most importantly, the multi-lines text need to be kept as is. Not automatically reformatted on one line. If unsure about this, I suggest to use a very small and simple text editor. Such as GEdit.

5. Using LO Calc, using cell A1, double check that the cell is presently configured with Calc defaults. Including, but not limited to, no text formatting of any kind. Do not make any change to the cell.

6. Before you proceed with the next step below. Heads up that both ...

[Francewhoa+bugs-documentfoundation-org (francewhoa+bugs-documentfoundation-org)]

Created attachment 167632
Screenshot---About_LibreOffice_7---Francewhoa---2020-11-27.jpg

Updated screenshot LO 7 "About"

[Iavs-leroy (iavs-leroy)]

Same results with:
Version: 7.2.3.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 1; OS: Linux 5.3; UI render: default; VCL: gtk3
Locale: es-MX (es_ES.UTF-8); UI: en-US
Calc: threaded

File in comment #9 is 235 lines, 1,409 characters with spaces, 1.4 kB size.
  Results in ~11 seconds lag per action. Calc is NOT usable :(

[Ilmari-lauhakangas (ilmari-lauhakangas)]

Might be related to accessibility, which is supported by gtk3, but not kf5. I only see the problem with gtk3.

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 9c796266470183f673eb58a8637dfe621eefa8b3
CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded

[Timur-y (timur-y)]

This is notBibisectable for me. Old GTK3 Calc doesn't run and GEN no repro.
Maybe it's not regression at all.

Workaround is to run Calc without GTK3, for example with qt5 or kf5:
 SAL_USE_VCLPLUGIN=kf5 soffice --calc

[Caolanm (caolanm)]

appears to be accessibility which is enabled on gtk3 rather than a direct gtk3 issue

[Caolanm (caolanm)]

https://gerrit.libreoffice.org/c/core/+/137497 is at least plausible to address this, repeated UpdateBoundRect() calls seem to be the major issue

[Libreoffice-commits (libreoffice-commits)]

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8e5c1982c41c234027245fe2da6bf9bc3f5fe238

tdf#108560 horribly slow to paste many lines into editeng with a11y active

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/85a1e6d32f7b7b2143162d78ed99b3dac686434e

tdf#108560 horribly slow to paste many lines into editeng with a11y active

It will be available in 7.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-4-0":

https://git.libreoffice.org/core/commit/81b5088a61b4202e8e8ce69c5bca5474482ed98b

tdf#108560 horribly slow to paste many lines into editeng with a11y active

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Timur-y (timur-y)]

It's a mystery to me why Assignee wasn't set and bug not marked Fixed when it really looks fixed when tested. I do it now. Thanks Caolan!