Description: i have a performance issue discussed in #124692, from latest tests i assume it resulting from plenty comments spread in the file, i can provide two test files - see next two comments - one with ~ 80 comments spread in A:J, and the other a copy where the comments are stripped out. pls. look at them and observe the cpu load (windows taskmanager) which occurs when just clicking around in the visible part of the sheet. i got significant differences, especially after minor changes in the files and the first subsequent autosave (autosave has to be on to see it). any help appreciated, and i think it'll make the program better when this problem is out. reg. b. Steps to Reproduce: 1. see description 2. 3. Actual Results: clicking in file with comments slower and producing cpu load Expected Results: no or neglectable difference in performance regarding comments contained in the file, as it was with former versions, Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha1+ (x64) Build ID: e92dcfdc7bd7b237e0bee26ff226a102d9e8e766 CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-14_00:00:57 Locale: de-DE (de_DE); UI-Language: en-US Calc: *unthreaded*
Created attachment 151727 [details] file producing cpu load when clicking around file producing cpu load when clicking around, sorry for the size, perhaps somebody can produce a more pinpointing version with less data and more comments,
Created attachment 151728 [details] file without comments and without problems a copy of the file producing cpu load when clicking around, comments are stripped out and performance is better, cpu load near zero, sorry for the size, perhaps somebody can produce a more pinpointing version with less data,
Created attachment 151730 [details] file producing cpu load when clicking around file producing cpu load when clicking around, sorry for the size, perhaps somebody can produce a more pinpointing version with less data and more comments,
What's the difference between this bug and bug 124692? Probably both have the same root cause... I don't think we need two different reports...
@xisco: yes, you're right, i *hope* i found the source of the problem, i started this bug / thread just as an shorter approach to the problem, i'm in doubt whether plenty people would invest the time and energy to read through the other thread ... at this moment i can confirm that the problem is still present in ver.: Version: 6.3.0.0.alpha1+ (x64) Build ID: 63b39fe87644587210214198fb67d6b3fb3343c5 CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-27_03:06:43 Locale: de-DE (de_DE); UI-Language: en-US Calc: *unthreaded*, imho it is important to kill this out, but may be i'm the only user with a big file using comments ... while i'm writing this my computer is busy for more than 30 minutes copying four rows of very simple test data without any formula (in columns A:CH), but with an comment - all the same - in about every tenth cell, to rows 1:12000. 'not responding', up to 25% percent of cpu load on a modern machine, aggressively eating memory, fans on to medium ... there is something too complicated with the representation and / or handling of comments, may be an erroneous recursion? after the copying the complete area is kept marked and nothing - neither mouseclick than cursor keys - produced 'workable effects' for the next hour, just cpu load and fan noise. just check yourself. (maybe it's an occurence of #76324, unresolved in the buglist for more than 5 years now) (imho a comment is a very simple data structure, a string related to only one cell, no formulas etc., such a thing shouldn't kill the program?) whoever likes to risk the usability of his computer is invited to load the file i'll provide with the next comment, save your other work beforehand! reg. b.
Created attachment 151749 [details] big file with plenty comments freezing systems this file rendered my system nearly useless, try with care!, try on your own risk, first save all open work and files! this time 6.3 has beaten ver. 4.1.6.2, in the later loading takes some time, first two tries to continue work ended in crash and freeze, of calc, not the system.
*** Bug 124692 has been marked as a duplicate of this bug. ***
@xisco: hello, after some testing i'm quite sure i stepped into a variant of https://bugs.documentfoundation.org/show_bug.cgi?id=76324 could you please use your position in the community to - get my 'analysis' (assumptions) rechecked, - raise the importance, - ask someone with skills to work on it? *** important point: may be some of the problem is only triggered after the first autosave of the file, thus 'quick and dirty' tests won't fail - to fail - and lead the testers to false 'not reproducible', 'my system is fast, must be your installation' or 'your file must be broken' assumptions *** *** may be it's even covered by or depending on other special conditions / settings or whatever, that could be a 'not so easy' job to determine, imho it must be done *** imho this is a very big mistake in the program, as it's infiltrating the work of affected persons with slowly evolving performance issues, which over the time produce bigger and bigger impact on their work, rendering the program unusable in the end. please help these people!!!
I can reproduce it in Version: 6.3.0.0.alpha1+ Build ID: aa687b22991e6c674b1d8653d52fbe9a50080174 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded and Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e so it looks like a dupe of bug 76324 *** This bug has been marked as a duplicate of bug 76324 ***
sorry for continuing here, the other thread is too long that anybody will read through it ... three observations: 1.) high cpu load is already triggered on hovering with the mouse / touchpad through the screen , you need not click anywhere, 2.) it is also triggered while hovering over an empty area of the screen, without any data or comments inside or belonging to the visible cells, 3.) things behave better - significantly better but far far away from fine! - when you save the file as 'fods', (Flat XML ODF spreadsheet), it's using plenty time the disk space but produces fewer delays / hangs / crashes or can handle singnificantly more cells and comments than with compression normally used for the file, one assumption: !!! it is only an assumption !!! might it be the case that comments are implemented as something like a 'one way referenced list', not having them inside the structure of the cells, but as a 'separate list', and with references which comment belongs to which cell only! in that list, but not having a reference at the cells where to look for the related comment? would be 'bad programming practice', even worse if the list is not sorted. that could explain plenty issues to me, everthing will work well while you have no or few comments, it's already a waste of ressources to check through that list on every mousemove, but it's done quickly and nobody complains about, once you have too many comments you have to check a long list ... on every mousemove!!! because you miss the path 'from coordinate to knowledge' and do a time consuming search instead, once the saved format is compressed that becomes very cpu-load-intense ... and one thought beyond the normal view: this issue is an ecological mess!!! besides wasting the time of plenty users in plenty plenty plenty little slices it's producing plenty plenty plenty plenty unneccessary cpu load on every mousemove of every calc user worldwide working in a file with commenst! and that wastes small but measureable pieces of energy, and plenty plenty plenty of them do! have an impact on global energy waste and thus contribute to ecological problems and climate change ... just my two cents, anybody laughing at me because he knows better ... should not laugh!!! - but share his knowledge where theese annoying performance impacts result from.