[Libreoffice-bugs] [Bug 124692] 6.3.0.0.alpha0+ calc slow in reaction on mouseclicks, editing

Mon May 27 18:05:51 UTC 2019

https://bugs.documentfoundation.org/show_bug.cgi?id=124692

b. <newbie-02 at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #11 from b. <newbie-02 at gmx.de> ---
>>> performance issue after autosave with 6.3.0.0alpha1+ 2019-05-14 <<<
>>> heavy cpu load and delayed reaction on mouseclicks <<<

hello @xisco, 

thks, you're right, as far as observed it's affecting only one of my files, 

!!! but that's not! solving the problem !!! 

(it is the biggest file i work with, and - unfortunately - the most important
data i work on :-(  )

i assume it's less the file being 'broken' but more some performance
deficiencies exploding above some level of size or complexity, 

@all: 

i did (tried) some test and analysis, with some but small effect, long story
below, 

short story: 

at this moment i can't  provide my 'big-file' for privacy reasons, but i can
provide four pictures showing an - imho -  massive bug / performance issue in
6.3.0.0alpha1+, see following comments with pictures, 

1. 'pic_problem_file_fresh_load_6_3_alpha1.jpg' - no problem, sheet
'responsive', 

2. 'pic_problem_file_after_autosave_6_3_alpha1.jpg' - massive delays and heavy
cpu load after a little change and autosave (autosave was finished, the load is
just from clicking around in the visible part of the sheet), 

3. 'pic_problem_file_after_autosave_4_1_6_2.jpg' - same situation as (2.) but
with version 4.1.6.2 - no delays, no load, no problem, 

the problem is affecting - 'only' - the reaction on mouseclicks, 

it is not! showing up after fresh load of the file, 

it is! triggered and showing up after the first - little - change in the file
and the subsequent autosave, 

it is not showing up in old versions, 

as long as this problem isn't identified any further analysis is useless, 

below a 'diary' of my way here, just if it's of any interest: 

at this moment i have four simple questions which people with skills may retest
or answer, 

- is it 'normal' that calc (6.3.0.0.alpha1+(x64)) produces load on more than
one cpu core despite being switched to *unthreaded*, 

- is it 'normal' that a file of 700 kB with a simple test pattern ('test' in A1
formatted as 'Arial 8', 'test1' in B1 formatted as 'Liberation Sans 10', these
expanded to fill A1:CH12000 in a checkerboard pattern) can! copy columns A:B to
CI:CJ, as well as to CK:CN, but reacts with *do nothing* when you try to copy
the same to CO:DO or CO:AMJ? (copying to CO:DO or CO:AMJ does! work in 4.1.6.2)

- is it 'normal' that above file which can be saved to disk in less than 5
seconds, takes more than 3:30 minutes for saving - factor ~70 (autosaving as
well) - with 4 to 5 burning! cpu-cores, once you expand it by a factor of 17
(fill the columns A:AMJ by copying filled rows instead of filled columns) which
will on disk fill about 7 MB? (in former tries i observed times up to 8 minutes
with entering 'unreponsive' short time after ctrl-s and leaving it after about
8 minutes), ok, the compression of the second file is somewhat better, but a
good packer should be able to compress both files to less than 10 kB, 8 kB for
calc overhead, 2 kB for data). (calc 4.1.6.2 does the save of the big file in
1:30 minutes instead of 3:30, using 5,5 MB instead of 7 MB on disk). 

- is it 'normal' that the cpu load for simply clicking around in the visible
part of a sheet increases by a factor of about 10 after the first autosave, see
pics 2 and 3 comments below this, one is from clicking around in the file after
a fresh load, it made about 100 clicks while CR-windows proceeded one width,
the other is the same action after the first autosave of the file, it made
about 40 clicks in the same time. 

i do! see significant limitations and performance issues - in a release
candidate? - and would like somebody with knowledge and motivation to step in
... 

below the diary of my testing ... if it's of any use ... 

thus i tried anonymizing it (my big file), foolishly i didn't make many copies
during that process - only 1 :-( , and after 5 hours of work i had the
impression that the problem might have gone ... not finally checked (as it
likes to occur after some time), i'll check further, 

i have two copies, one with columns A:R anonymized, looks already 'fast', one
with A:BU anonymized, looks fast either, 

i know, i have to check and compare these files against the original, it'll
boil down the problem ... 

why do i write this ... ??? 

- as the check will be at least another 5 hours of work any hint or help which
part of the data might be 'broken' would be highly appreciated, 

- it's help for me to do a structured and documented analysis, 

- it might help other people if they ever have similar problems, 

- i have some assumptions, may be someone can say something on them, 

a.) i lost some formatting (colored backgrounds, font types and similar) during
anonymizing, is anything of that known to be critical for speed? 

!!! the only 'speed problem! i have is the delayed reaction on mouseclicks,
other things as 'keying in', reaction on cursor keys, calculations etc. work
fine (afais)!!!

same for data, i replaced plenty different obscure content with 30 random clean
strings (limit of 'choose'), are either 

b.) 'unclean' formattings (text as numbers or vice-versa, or similar), 

c.) too many different items per column - especially if autofiltered, or 

d.) 'special content' as e.g. "...", "?" or "???" (without the quotes) or
similar (i remember an excel problem of a file with "..." dying in xls format
(slowed down by factor 500 and frequent crashes), it came back to live in xlsx
format but that was two years too late), or 

e.) commented cells (i lost comments too on replacing cells with random text),
or 

f.) anything else what didn't make it into my focus yet, 

known or 'more suspicious' to cause such problems? 

just in this point of writing i had one idea, i have a 'evaluation region' of
the 6 top rows containing calculation of the whole table (mainly 26
subtotals(9;(Xn:Xm)), calculating sums of the part of the columns visible after
filtering, simple calculations between these subtotals and one cell summing 6
'subarea totals' which are each sums of 4 'subcolumns totals' from within the
sheet), some of these formulas where replaced with 'values' when i columnwise
replaced the randomized cells with 'formula to text' (ctrl-c - shift-ctrl-v), 

i 'repaired' this 'simplyfication' by overpasting the original formulas
(big-data_a), the sheet was still 'responsive', after a save and reload cycle:
sheet with delays! 

funny, funny, funny, any helpful comment appreciated, comments about 'wrong
place to discuss' superfluous, hints where to continue appreciated, 

!!! re-checked, the anonymized and simplyfied (regarding the formulas) file is!
'fast', it stays sane (fast) after overpasting the formula area, it gets the
'illness' instantly after saving (with a different name (big-data_b)) !!!

!!! counter-checked, the original file keeps it's 'iodrom' (illness of delayed
reaction on mouseclicks) over simplifying the evaluation area
(finlist-defective), also over save-as, it is fast after reload - as the
original is fast for some time after every reload -, now i have to wait up to
two hours to see if there is a difference over time, if not: 'louses and
fleas'? !!!

after about one hour: big-data_a: still ill, big-data_b: still ill,
finlist-defective (simplyfied): still responsive, finlist-original: still
responsive (file cured by saving a copy of it?), 

it looks as i'm approaching to the source ... but yet somewhat confusing ... 

clearly observed, the problem shows up in finlist-original after some wait,
some minor changes, and! the first 'auto-recovery-save' with the running ants
on the floor, 

after some wait: big-data_a slow, 2 sec., big-data2 slow, 2 sec., big-data_b
slow, 2sec., finlist-original slow, 2sec., finlist-defective (without
subtotals) slow, 1,5 sec., all files fast when filtered to show less lines of
data than fit on the screen, 

seen aside, i do! have different fonts within the documents, that's not
intentional but occurring from former experimenting and copying data from other
files, i'll try to change that, 

after! setting the font for all cells to 'arial 8' and saving with new name the
mouseclicks remain slow and 'running ants' occur commented 'adapt row hight' or
similar, (big-data_a_2), 

after setting all cell formatting to liberation sans narrow and 'save as' still
delays and running ants, (big-data_a_3),  

after close and reload: fine and fast ... ??? 

thought to proceed with 

- how to find cells with dedicated formatting, 

- wait how it performs over time, 

after some wait, some changes, also the file with unified formatting becomes
slow, may be not as slow as the others, but in a way slow too ... 

frustrated, 

finding formattings is ... 'not so easy', at least not if you don't know what
you should search for, 

a new idea: 

when clicking around i'm producing processor load, 'visible' from the fans of
the laptop producing noise ... 

pic_unified_formatting: task manager cpu load while clicking around in a big
file with - mostly - unified formattings, 

pic_empty_file: task manager cpu load while clicking around in an empty file, 

pic_problem_file: task manager cpu load while clicking around in my problematic
file, 

(all done with *unthreaded*, i'm not going to test *threaded* while it's
producing errors reg. other bugs) 

i do! see significant load, and i do! see significant differences, 

as the 'work' done is NOTHING! else than clicking on other places - cells - in
the visible and unmoved part of the sheet, thus changing the focus to another
cell, i do not understand why any computation has to be done, or any cpu load
has to be produced, and it's neither way acceptable to have such high load and
waste of energy. 

i heard that there are people who care for the performance and do cryptic
things like 'shared formulae groups' - which they don't have in good control -,
just to save some percent of space and operations, pls.!!! let somebody step in
and kill out this problem before it renders all these efforts useless ... 

at this point i boiled down the problem to two short questions you find in the
beginning of this post, 

i'll continue work next time i find some spare time, 

best regards,  

b.

P.S. anyone doubting my talent as 'fault-finder'? the spell checker of the
comment editor marked 'formattings' as wrong, deepl says it's the right
translation for the german word 'Formatierungen'

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190527/bad53089/attachment-0001.html>