Bug 108560 - Editing multi-line cells with thousands of words is slow when OpenGL is enabled
Summary: Editing multi-line cells with thousands of words is slow when OpenGL is enabled
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.6.3 release
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, perf, regression
Depends on:
Blocks: Cell-Edit-Mode
  Show dependency treegraph
 
Reported: 2017-06-16 00:13 UTC by Francewhoa
Modified: 2019-01-15 03:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods (14.04 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-16 00:13 UTC, Francewhoa
Details
calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods (7.11 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-16 00:21 UTC, Francewhoa
Details
lorem_ipsum---Francewhoa---2017-06-15.txt (77.09 KB, text/plain)
2017-06-16 00:22 UTC, Francewhoa
Details
screenshot---About_LibreOffice---Francewhoa---2017-06-15.jpg (43.22 KB, image/jpeg)
2017-06-16 00:24 UTC, Francewhoa
Details
Dependencies.txt (3.31 KB, text/plain)
2017-06-17 17:00 UTC, Francewhoa
Details
lorem_ipsum---129_lines---773_characters---Francewhoa---2017-06-17.txt (774 bytes, text/plain)
2017-06-17 21:43 UTC, Francewhoa
Details
lorem_ipsum---235_lines---1409_characters---Francewhoa---2017-06-17.txt (1.38 KB, text/plain)
2017-06-17 21:44 UTC, Francewhoa
Details
lorem_ipsum---470_lines---2819_characters---Francewhoa---2017-06-17.txt (2.75 KB, text/plain)
2017-06-17 21:44 UTC, Francewhoa
Details
lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt (5.51 KB, text/plain)
2017-06-17 21:45 UTC, Francewhoa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francewhoa 2017-06-16 00:13:18 UTC
Created attachment 134057 [details]
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:
• Version: 5.2.7.2
• Build ID: 1:5.2.7-1~bpo8+1
• CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: gtk3;
• Locale: en-CA (en_CA.utf8); Calc: group
• Java 1.8.0_131 Oracle Corporation

System:
• Base: Debian 8.8 Jessie, 64-bit
• 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


Hardware:
• Ram: 31GB. Only LibreOffice is open and active.
• Processor: Intel Core i7 @ 3.10 GHz
• CPU: 8


• Similar challenges:
...• https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999
...• https://askubuntu.com/questions/925383/libreoffice-calc-is-slowing-down-when-working-with-big-cells
...• https://ask.libreoffice.org/en/question/75074/libreoffice-5204-unbearably-slow-on-ubuntu-1404/

I would be happy to contribute testing and documentation if needed

Let me know if you have any questions or need anything else

Cheers,

Francewhoa
Comment 1 Francewhoa 2017-06-16 00:21:23 UTC
Created attachment 134058 [details]
calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods
Comment 2 Francewhoa 2017-06-16 00:22:55 UTC
Created attachment 134059 [details]
lorem_ipsum---Francewhoa---2017-06-15.txt

Text used to reproduce this challenge
Comment 3 Francewhoa 2017-06-16 00:24:02 UTC
Created attachment 134060 [details]
screenshot---About_LibreOffice---Francewhoa---2017-06-15.jpg
Comment 4 Telesto 2017-06-16 17:03:44 UTC
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)
Comment 5 Francewhoa 2017-06-17 17:00:15 UTC
Created attachment 134084 [details]
Dependencies.txt

Shorter text file for testing. With 130 lines. Thanks to smagoun :)
Comment 6 Francewhoa 2017-06-17 17:18:48 UTC
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.
Comment 7 Francewhoa 2017-06-17 21:42:50 UTC
I'll post shortly 4 new files which I used to further narrow down the source(s) of the issue
Comment 8 Francewhoa 2017-06-17 21:43:26 UTC
Created attachment 134088 [details]
lorem_ipsum---129_lines---773_characters---Francewhoa---2017-06-17.txt
Comment 9 Francewhoa 2017-06-17 21:44:12 UTC
Created attachment 134089 [details]
lorem_ipsum---235_lines---1409_characters---Francewhoa---2017-06-17.txt
Comment 10 Francewhoa 2017-06-17 21:44:47 UTC
Created attachment 134090 [details]
lorem_ipsum---470_lines---2819_characters---Francewhoa---2017-06-17.txt
Comment 11 Francewhoa 2017-06-17 21:45:44 UTC
Created attachment 134091 [details]
lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt
Comment 12 Francewhoa 2017-06-17 22:07:10 UTC
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.
Comment 13 Telesto 2017-06-24 17:52:55 UTC Comment hidden (obsolete)
Comment 14 Buovjaga 2017-06-28 10:27:26 UTC
(In reply to Telesto from comment #13)
> Maybe a dupe of bug 84099 ?

Nope, bug 84099 already appears with 4.2.0.
Comment 15 Telesto 2018-01-14 15:38:52 UTC
(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
Comment 16 Buovjaga 2018-01-14 16:55:15 UTC
(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...
Comment 17 Buovjaga 2018-01-14 17:28:44 UTC
Um, I don't get any slowness from pasting attachment 134059 [details] 
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
Comment 18 Telesto 2018-01-14 19:06:31 UTC
(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
Comment 19 QA Administrators 2019-01-15 03:48:34 UTC
** 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