Description: for some month now i am 'investigating' in an old bug, #76324, 'calc becoming slow once you have too many comments in a sheet'. >>> this bug refers to that old bug, it is not! a duplicate of it as it describes a significantly changed behaviour, thus pls. take it serious instead pulling it out of sight as duplicate <<< anyone can be lucky once and again, i found one specific version of libreoffice where this problem is mitigated. funnily enough it's better in the windows x64 version of 6.2.7.1, while still massively present in in the parallel version for linux. i kindly ask for help: - could someone retest and confirm this, - when confirmed, could someone dig into the code or just compare the win and linux version to find the difference, (would that work with bibisect?). - once found, could someone implement the enhancements from the win version in all development streams, (the performance issue is! still present in all 6.3 versions i tested). once confirmed i hope it's possible for the developers to dig for the differences either in code or in handling by the OS, and to improve the buggy versions. Steps to Reproduce: 1. in ver. 6.2.7.1 for windows start with an empty sheet, 2. add any comment to cell A1, 3. copy and paste that cell to a bigger region, say A1:AX50, that'll be 2.5 k commented cells, 4. observe the program performing normal. (ok, it will take some time, it depends on your system, and it's unnormal long compared to just copying cells without comments, but it'll finish in an acceptable time.) 5. do the same in ver. 6.2.7.1 for linux (concrete info below), 6. observe system load e.g. in a terminal window running 'top'. on my system about 45 minutes to finish the insert, and 100% cpu load for all that time. (linux version tested is slightly exotic, 'kali', but behaves normal on plenty other tasks i ran on it, as well as with plenty calc spreadsheets without or with only a few comments). Actual Results: win version much! faster than linux, linux version nearly dying from the system load, (that is not the performance of 'the spreadsheet you ever wanted') Expected Results: both versions with better speed, especially under linux, wishlist: handling of a cell with comments should be as performant as handling of any other cell. Reproducible: Always User Profile Reset: No Additional Info: Windows version with significantly enhanced performance: Version: 6.2.7.1 (x64) Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: *unthreaded* Linux version still buggy: Version: 6.2.7.1 Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: de-DE (en_US.UTF-8); UI-Language: en-US Calc: *unthreaded* stress-test to see that also the enhanced win version is still buggy: 0. any version of lbreoffice calc, 1. empty sheet, 2. enter '1' in A1 - without the quotes, 3. copy A1 - ctrl-c, 4. mark column A - by click on the header, 5. paste - ctrl-v, 6. observe 'done on the fly', 7. delete all that content - 'del', 8. add comment '1' to cell A1 - without the quotes, 9. copy A1 - crtl-c, 10. mark the whole column a - by click on the header, 11. gallows humor: kiss your program goodnight, it won't talk to you anymore 12. paste - crtl-v, 13. observe 'program dead', 14. try the same procedure with ver. 6.2.7.1 win-x64, 15. observe 'dead too', 16. if you find any version not dying on step 12 please give me a note.
Considering the time you spent on it, I think you might be interested in building LO from sources to retrieve more information or for coding? (see https://wiki.documentfoundation.org/Development) At least, a Flamegraph may help to find bottleneck. About Linux/Windows difference, it may be related to renderings. You can try different renderings on Linux: gtk3, kf5 (= kde5), gen. for example, on console, type: SAL_USE_VCLPLUGIN=gen;soffice --calc or SAL_USE_VCLPLUGIN=kf5;soffice --calc
For Linux, the pb is in sc/source/ui/Accessibility/AccessibleDocument.cxx. Indeed, when using "gen" rendering, it's far more faster than "gtk3". "gen" rendering doesn't use accessibility part.
@Julien Nabet, hello, and thanks for your help, i tried the different rendering machines, they do! have an impact on performance, but i measured times between 1:15 and 2:30 minutes for the paste of a cell with a comment to 2.500 empty cells, that's very little compared to the mentioned win version completing this task in less than 5 seconds, thus it's not touching the core of the problem. i'd like you - and others - to retest my steps and report wether they find 'normal' behaviour or disturbing delays. btw.: also with the 'best yet seen' version, 6.2.7.1 win x-64, filling one column in total with commented cells leeds to 'not responding' and not finishing the task, requiring an external kill. reg. coding and flamegraphs, - i tried installing a development environment some time ago, was stuck in an incompatibility between some 32 vs. 64 bit components, and will retry once i have more time for that, - i doubt if it's a good idea to let newbies reprogram difficult code, i'm talented in pinpointing errors, i'm not motivated to replace them with better errors from me, - i didn't work full time on this issue, i'm very well stretched by my normal job, - thus i'd like help from others with: -- retest the issue, just to rule out me, my machine, my system or my configuration being drunk or bad, (it's very easy, copy one commented cell to a full column, compare with that the copy of an uncommented cell works on the fly) -- once confirmed i'd like people experienced with coding, profiling and flamegraphs to take over and care for that issue, imho. that's the idea behind a community, people combining their special talents and knowledge to improve the product and learn fom each other. reg. b.
When I saw the time it takes just when copying the cell with comment on a large range, I stopped here and launched Flamegraph. Noel found the bottleneck, I think it's not the only one but we must tackle it first. I'm waiting for his feedback because not sure about what he means. Concerning dev contribution: About build problems, you can send a message on LO Dev forum or ping LO dev IRC. About buggy patches, don't be afraid to give a try since they're reviewed by devs on gerrit. Now it was just a suggestion, no obligation of course! :-)
@Julien Nabet thank you, it's a big relief for me to read that someone is taking care of this and making progress, i tried to install 'dev' (this time on linux, former try was windows), the video tutorial was helpful and only Kerberos was missing, my system does the first 'make', it takes a while ... a long while ... i would be happy if you could post the flamegraph, it could help more people to take the problem seriously, and give me an idea what i was fighting against ... if you have the 'power' please set the bug to 'new', thank you very much, b.
b.: Flamegraph is here: https://bugs.documentfoundation.org/show_bug.cgi?id=76324#c75 Xisco: should we close tdf#76324 because there's already a long history and keep on this one?
(In reply to Julien Nabet from comment #6) > b.: Flamegraph is here: > https://bugs.documentfoundation.org/show_bug.cgi?id=76324#c75 > > Xisco: should we close tdf#76324 because there's already a long history and > keep on this one? well, same story here. the first comment is 200 lines long, very inconvenient for reading...
Anyway, I don't know why this issue got back to UNCONFIRMED. it's a clear duplicate of bug 76324 *** This bug has been marked as a duplicate of bug 76324 ***
@Xisco: did you read this? 'this bug refers to that old bug, it is not! a duplicate of it as it describes a significantly changed behaviour, thus pls. take it serious instead pulling it out of sight as duplicate' sorry, my comments are long, but 54 (plus some whitespace) is not 200, i feel it's neccessary to use some more words when trying to get attention to a bug: - whose root ist many years old, - and which is not / only partly solved after hundreds of comments with few words which are convenient to read ... and: a bug nearly resolved in win-ver while still present in lin-ver must not! be the same as one affecting both versions, not finally tested, seems win 6.4 is bad again, pls. also take https://bugs.documentfoundation.org/show_bug.cgi?id=125619#c9 and previous from 125619 into account reg. b.