Description: since about 2 weeks i observe a delay of about two seconds in the new daily versions when calc has to simply change the focus to another cell after a click in that cell. after that time the border of the new cell is enhanced an i can continue. former versions reacted instantly to clicks. affected is a large tabel with ~10.000 rows, ~100 columns, plenty but simple formulas, no circulars, Steps to Reproduce: load a large table, click in a cell, lokk how fast the focus - fat border - will change towards that cell. Actual Results: slow Expected Results: fast Reproducible: Always User Profile Reset: No Additional Info: 6.3.0.0.alpha0+, unthreaded, don't know if threaded is affected too,
please add info from dialog Help->About LibreOffice can you make a screencast with problem and attach it here?
> please add info from dialog Help->About LibreOffice Version: 6.3.0.0.alpha0+ (x64) Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4 CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04 Locale: de-DE (de_DE); UI-Language: en-US Calc: did not provide in original report because multiple versions were affected, > can you make a screencast with problem and attach it here? i think i should be able to create a video direct from screen, but don't know an appro. tool for that, will google it later, video created with handycam will bee to big and require 'overwork', it was: 5 mb, 10.000+ rows, A:CG columns spreadsheet, having the focus in one cell, clicking with the touchpad on a cell nearby, counting twentyone - twentytwo, see focus changing towards the new cell. and just now when i wanted to make two screenshots the problem disappeared ... ?!?! only changes inbetween: restarts of calc withe 'threaded' toggled on and off, and close, save and load of files, but i did the same before and the problem persisted ... ? :-( while i do not come back pls. set to 'worksforme', but leave as reference if others experience similar problems. reg. b.
Created attachment 151197 [details] 4_1_6_2_fast_reaction it 'happened again', 6.3.0.0 being slow in reaction on mouseclicks, it happened short time after i closed this bug as worksforme, but took till today to find time to report about ist. this video is my 'big file' opened with LO-calc 4.1.6.2 and just 'clicking around'. sorry, the video doesn't show the cursor, assume i always clicked within half a second after the focus adjusted to the last click.
Created attachment 151198 [details] 6_3_0_0_fresh_after_load it 'happens' in a special way - to be slow -, initially after loading the file the reaction on mouseclicks is spontaneous as expected ...
Created attachment 151199 [details] 6_3_0_0_after_some_waiting ... and after some time, in this case after 1 hour of other work with other programs in other files without touching this file, just having it opened, the reaction is slow, after a click i can count 'twentyone - twentytwo - twentythree' and then the focus jumps to the desired position. it's a pain to work like that, if anyone can change it i'd be very grate- and thankful. reg. b.
happenes also in ver: Version: 6.3.0.0.alpha0+ (x64) Build ID: ccf3a0600ee902390ad6112ecf28223078bdd2db CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-13_03:08:59 Locale: de-DE (de_DE); UI-Language: en-US Calc: *unthreaded* (may be with *threaded* too ...???
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
hello, problem with the file ... too big, too many things to change before it could be undisclosed, thus i made the videos, i hope one can see the slowiness, if not i can't help, if there are no other persons with similar problems, i can't help :-(
(In reply to b. from comment #9) > hello, > > problem with the file ... too big, too many things to change before it could > be undisclosed, > > thus i made the videos, i hope one can see the slowiness, if not i can't > help, > > if there are no other persons with similar problems, i can't help > > :-( Hello, So I assume it's only happening with one file. In that case it should be attached ( after it's sanitized ), otherwise, there isn't much we can do from QA
>>> 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'
Created attachment 151708 [details] pic_problem_file_fresh_load_6_3_alpha1 cpu load while 'clicking around' in the file after loading it,
Created attachment 151709 [details] pic_problem_file_after_autosave_6_3_alpha1 cpu load on same action - clicking around - after one minor change in the file and the file being 'autosaved' (saved autorecovery information), just 'clicking around' in the file produces heavy cpu load and delays,
Created attachment 151710 [details] pic_problem_file_after_autosave_4_1_6_2 in calc version 4.1.6.2 'everything is ok' also after! a change in and autosave of the file, no delays, no cpu-load,
Since we have documents in bug 125545. Let's close this one as a dupe of the other one *** This bug has been marked as a duplicate of bug 125545 ***