Created attachment 134057 [details]
Hi LibreOffice enthusiasts :)
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 220.127.116.11
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 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 18.104.22.168. This issue can not be reproduce on LibreOffice 4.2.
• Using 22.214.171.124, 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"
• 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?
• Version: 126.96.36.199
• 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
• 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
• Ram: 31GB. Only LibreOffice is open and active.
• Processor: Intel Core i7 @ 3.10 GHz
• CPU: 8
• Similar challenges:
I would be happy to contribute testing and documentation if needed
Let me know if you have any questions or need anything else
Created attachment 134058 [details]
Created attachment 134059 [details]
Text used to reproduce this challenge
Created attachment 134060 [details]
I do notice quite some lag with:
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
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa-GL
Locale: en-US (nl_NL)
but not with
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: nl-NL (nl_NL)
Created attachment 134084 [details]
Shorter text file for testing. With 130 lines. Thanks to smagoun :)
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 188.8.131.52 Telesto was NOT able to reproduce
• With LO 184.108.40.206 Telesto was ABLE to reproduce
• With LO 220.127.116.11 Francewhoa was ABLE to reproduce
• With LO 18.104.22.168.alpha0+ Telesto was ABLE to reproduce
So it seems something was introduce between 22.214.171.124 and 126.96.36.199
#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.
I'll post shortly 4 new files which I used to further narrow down the source(s) of the issue
Created attachment 134088 [details]
Created attachment 134089 [details]
Created attachment 134090 [details]
Created attachment 134091 [details]
• 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 188.8.131.52. 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.
Maybe a dupe of bug 84099 ?
(In reply to Telesto from comment #13)
> Maybe a dupe of bug 84099 ?
Nope, bug 84099 already appears with 4.2.0.
(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
(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...
Um, I don't get any slowness from pasting attachment 134059 [details]
Please test with a recent build.
Arch Linux 64-bit
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
(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:
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
** 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!
Not yet fixed by Version: 184.108.40.206 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.