Launchpad has imported 38 comments from the remote bug at https://bugs.documentfoundation.org/show_bug.cgi?id=108560.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2017-06-16T00:13:18+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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: • 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/15 ------------------------------------------------------------------------ On 2017-06-16T00:21:23+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134058 calc_spreadsheet---before---Slow_Edit_Large_Cell---Francewhoa---2017-06-15.ods Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/16 ------------------------------------------------------------------------ On 2017-06-16T00:22:55+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134059 lorem_ipsum---Francewhoa---2017-06-15.txt Text used to reproduce this challenge Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/17 ------------------------------------------------------------------------ On 2017-06-16T00:24:02+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134060 screenshot---About_LibreOffice---Francewhoa---2017-06-15.jpg Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/18 ------------------------------------------------------------------------ On 2017-06-16T17:03:44+00:00 Telesto wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/20 ------------------------------------------------------------------------ On 2017-06-17T17:00:15+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134084 Dependencies.txt Shorter text file for testing. With 130 lines. Thanks to smagoun :) Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/24 ------------------------------------------------------------------------ On 2017-06-17T17:18:48+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/25 ------------------------------------------------------------------------ On 2017-06-17T21:42:50+00:00 Francewhoa+bugs-documentfoundation-org wrote: I'll post shortly 4 new files which I used to further narrow down the source(s) of the issue Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/26 ------------------------------------------------------------------------ On 2017-06-17T21:43:26+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134088 lorem_ipsum---129_lines---773_characters---Francewhoa---2017-06-17.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/27 ------------------------------------------------------------------------ On 2017-06-17T21:44:12+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134089 lorem_ipsum---235_lines---1409_characters---Francewhoa---2017-06-17.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/28 ------------------------------------------------------------------------ On 2017-06-17T21:44:47+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134090 lorem_ipsum---470_lines---2819_characters---Francewhoa---2017-06-17.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/29 ------------------------------------------------------------------------ On 2017-06-17T21:45:44+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 134091 lorem_ipsum---940_lines---5639_characters---Francewhoa---2017-06-17.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/30 ------------------------------------------------------------------------ On 2017-06-17T22:07:10+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/31 ------------------------------------------------------------------------ On 2017-06-24T17:52:55+00:00 Telesto wrote: Maybe a dupe of bug 84099 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/36 ------------------------------------------------------------------------ On 2017-06-28T10:27:26+00:00 Ilmari-lauhakangas wrote: (In reply to Telesto from comment #13) > Maybe a dupe of bug 84099 ? Nope, bug 84099 already appears with 4.2.0. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/37 ------------------------------------------------------------------------ On 2018-01-14T15:38:52+00:00 Telesto wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/38 ------------------------------------------------------------------------ On 2018-01-14T16:55:15+00:00 Ilmari-lauhakangas wrote: (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... Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/39 ------------------------------------------------------------------------ On 2018-01-14T17:28:44+00:00 Ilmari-lauhakangas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/40 ------------------------------------------------------------------------ On 2018-01-14T19:06:31+00:00 Telesto wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/41 ------------------------------------------------------------------------ On 2019-01-15T03:48:34+00:00 Qa-admin-q wrote: ** 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/42 ------------------------------------------------------------------------ On 2020-01-29T08:28:32+00:00 Jacques wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/43 ------------------------------------------------------------------------ On 2020-08-28T13:09:57+00:00 Ilmari-lauhakangas wrote: (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/ Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/44 ------------------------------------------------------------------------ On 2020-11-27T23:36:40+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/45 ------------------------------------------------------------------------ On 2020-11-27T23:38:25+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/46 ------------------------------------------------------------------------ On 2020-11-28T01:27:46+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/47 ------------------------------------------------------------------------ On 2020-11-28T05:09:37+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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". Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/48 ------------------------------------------------------------------------ On 2020-11-28T05:36:29+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/49 ------------------------------------------------------------------------ On 2020-11-28T05:55:56+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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 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 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? --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 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 • My guess is that somehow Calc tries to validate the cell. 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 validation over. In turn, this is repeated at each line. Until Calc reaches the last line. But there is nothing to validate. 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/50 ------------------------------------------------------------------------ On 2020-11-28T06:07:56+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/51 ------------------------------------------------------------------------ On 2020-11-28T06:10:49+00:00 Francewhoa+bugs-documentfoundation-org wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/52 ------------------------------------------------------------------------ On 2020-11-28T06:36:18+00:00 Francewhoa+bugs-documentfoundation-org wrote: Created attachment 167632 Screenshot---About_LibreOffice_7---Francewhoa---2020-11-27.jpg Updated screenshot LO 7 "About" Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/53 ------------------------------------------------------------------------ On 2022-07-03T21:19:38+00:00 Iavs-leroy wrote: 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 :( Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/54 ------------------------------------------------------------------------ On 2022-07-04T06:40:00+00:00 Ilmari-lauhakangas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/55 ------------------------------------------------------------------------ On 2022-07-04T14:30:02+00:00 Timur-y wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/56 ------------------------------------------------------------------------ On 2022-07-27T08:19:43+00:00 Caolanm wrote: appears to be accessibility which is enabled on gtk3 rather than a direct gtk3 issue Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/57 ------------------------------------------------------------------------ On 2022-07-27T10:41:41+00:00 Caolanm wrote: https://gerrit.libreoffice.org/c/core/+/137497 is at least plausible to address this, repeated UpdateBoundRect() calls seem to be the major issue Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/58 ------------------------------------------------------------------------ On 2022-07-27T15:09:11+00:00 Libreoffice-commits wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/59 ------------------------------------------------------------------------ On 2022-07-28T10:27:02+00:00 Libreoffice-commits wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1034999/comments/60 ** Changed in: df-libreoffice Status: Unknown => Confirmed ** Changed in: df-libreoffice Importance: Unknown => High -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1034999 Title: libreoffice-calc very slow to open/save documents with large cell contents Status in LibreOffice: Confirmed Status in libreoffice package in Ubuntu: Confirmed 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) 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) To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1034999/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
