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

Created attachment 134059 [details]
lorem_ipsum---Francewhoa---2017-06-15.txt

Text used to reproduce this challenge

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

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)

Created attachment 134084 [details]
Dependencies.txt

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

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

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

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

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

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

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.

(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
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

(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

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.

(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/

Comment on attachment 134059 [details]
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

Comment on attachment 134084 [details]
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

Created attachment 167628 [details]
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.

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

Created attachment 167629 [details]
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.

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 the Calc and all other LO applications will likely hang for an extended period of time. Maybe for 15 minutes. During that period, all LO applications are not usable and 100% of a CPU is permanently use. So before proceeding with the next step below, I suggest to either use a virtual environment, or save all your valuable opened documents. As it's likely that you will need to kill LO Calc to resume using LO. Which risk to result in both valuable time lost and data lost.

7. Still using LO Calc, still using cell A1, paste the text as as plain text.

8. LO hangs. This is the FIRST challenge:
______• This hang ranges from seconds to minutes depending mostly on the number of multi-lines text
______• During this hang, one CPU is running at 100%.
______• In my case, Calc needs 14 minutes to process this one simple paste operation for this file "lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt"
______• After this hang the text is pasted
______• In this Comment 24 above, the attached spreadsheet shows the end result after this step is done. The file is titled "calc_spreadsheet---after---Slow_Edit_Large_Cell---Francewhoa---2020-11-27.ods"

9. Double click on this cell A1 to open it. LO hangs again. This is the SECOND challenge. And so on. In other words, at each paste, or edit, this cell result in a hang. Thus LO and all its application are unusable. Because at each operation the hang returns. As of November 27th, 2020 we were able to reproduce this challenge on multiple devices. With freshly installed LO ranging from versions 5 to 7.

10. If somehow you're not able to reproduce this challenge, I suggest to double that you use the same steps as above as is, and using the attached files. Otherwise it is risky that you won't be able to reproduce. Also double check that the text editor you use to copy paste the text, does not do any operation on the text without notifying you or asking you to confirm. Optionally, for testing shorter hangs or long hangs, I attached smaller test files into:
• Comment 8
• Comment 9
• Comment 10
• Comment 11
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 



Expected outcome:

• Expected result is the text should be pasted into the cell within ~1 second. Or edited within ~1 second. Which are the fast performance back in the time of dinosaur with LO 4.2 ;) Not ~30 seconds not 15 minutes with the present LO version 7. 30 seconds is very fast if we need to do one operation within ~one day. But the challenge 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. Per operation. Which is too slow. And not usable. 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.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 



Suggested resolution:

• How about resolving this with this attached mockup titled "mockup---suggested_resolution---francewhoa---ksnip---2020-11-27_nov---v2.jpg"? at https://bugs.documentfoundation.org/attachment.cgi?id=167629
Where:
___• Number 1 shows the user using "Format Cells" on a selected cell(s)
___• Number 2 shows the user clicks on "Cell Protection" horizontal tab
___• Numbers 3 & 4 show a new group titled "XML Parse Buffer". With a new checkbox titled "Do not parse". Using simply check this new "Do not parse" box. Bingo done. Resolved.
____ With help text reading "If checked, the cells selected will be ommited from the automated XML Parse Buffer operations. Which may result in speed increase for operations such as pasting or editing multi-line cells. To the cost of automated operations by the XML Parse Buffer." 
___• By default this "Do not parse" check box is not checked. So that no change are made to past or future spreadsheets. But interested users, like me, would be able to check this box per cell. Thus speeding up multi-line cells. Similar to faster performance back with LO 4.2.
___• I'm not a developer, I'm both a quality assurance/tester & end-user. Attribution to Steve Magoun for the inspiration about the title "XML Parse Buffer". This is just a mockup to facilitate communications, of course both this suggested title and its help text could easily be adapted. To better reflect what is the primary cause of this challenge. After it is identified.

• 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 do those batch operations on the full content of the cell. If so, how about allowing the user to deactivate such automated operations per cell, per sheet, per spreadsheet, per LO global setting?
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 



What we tried that was EFFECTIVE:

• Using LO 4.2. Instead of 5.2.7. This issue can not be reproduce on LO 4.2.
• Using 5.2.7, 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.
• Using Microsoft Excel .xlsx files. This issue can not be reproduce.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 



What we tried that was INEFFECTIVE:

• Use LO 7.0.3.1. Instead of 5.2.7.
• Use LO 6.1.5. Instead of 5.2.7.
• Activate OpenGL or deactivate OpenGL. Same results.
• "Format" menu > "Cell" option > "Numbers" > Text 
• "Format" menu > "Clear Direct Formatting" option 
• Increase memory at “Tools > LO > Memory“
• Force LO to use the latest installed Java 1.8 at “Tools > Options > LO > Advanced > Expert Configuration”
• Close the LO sidebar
• "Format" menu > "Cell" option > "Alignment" > unchecked "Wrap text automatically" 
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 



Speculation:

• The amount of multi-lines text in the cell is directly correlated to the length of the hang. So 470 lines is roughly double the hang time than 235 lines. And so on.
• This challenge is maybe related to the XML_ParseBuffer() and its children. Details and trace output at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/3
  https://archive.md/3mYFs
• My guess is that somehow Calc tries to do a large amount of automated operations on the cell. But within the context of the above steps to reproduce, those operation are done but not needed. In turn, within the cell, each time Calc reach the end of a line, Calc detect a break line, also called text wrapping, somehow this restart the automated operations on the cell over. In turn, this is repeated at each line. Until Calc reaches the last line. But there is nothing to do operation with. No calculation. No text formatting. No condition. No nothing on that cell. Except plain text.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 



Similar challenges:

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



Any volunteer for a patch? 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

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

Updated screenshot LO 7 "About"

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 :(

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

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

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

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

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.

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.

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.

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!