Michael Meeks

@sopyb this might be an interesting one to look at too - quite some code pointers; I expect that its necessary to have a sheet with a lot of columns...

Ok - the same fundamental problem in all of these - probably caused by unusual sheet geometry - but we should fix it anyway: https://github.com/CollaboraOnline/online/issues/11341 describes the issue.

The lack of background save which is excessively visible above is down to this: https://gerrit.libreoffice.org/c/core/+/182931 needing merging - would appreciate a review from @caolanm there really :-)

Latest profile looks like a typical case of someone filling a whole row with text and hugely expanding the sheet data-containing range - which is deeply unhelpful for rendering performance....

Interesting - saving looks like we are not doing background saves which is unexpected and problematic. I _expect_ that some new thread is being used there that stops us from...

Seems we don't have BufferedDecompositionFlusher - but we do need to be able to shut-down and re-start those threads for the future in desktop/source/lib/init.cxx (lo_joinThreads) :-)

If someone can reproduced a non-background save - then please attach gdb if you can to the process - and get a: "thread apply all backtrace" trace so we can...

Interestingly: ``` ThreadDropper threadGuard; if (!threadGuard.dropThreads(this)) { LOG_WRN("Failed to join threads before async save"); ``` Suggests no hits of this in share or staging-perf's journals: ``` journalctl --grep 'Failed to...

@grandinj that UpdateCursorOverlay looks like a silly one - I expect there are two problems: gamer mice with multiple mouse events queued each of which takes too much time to...

The preceding profile suggest that the 'ScViewFunc::PasteFromClip' is doing this massive 'AdjustBlockHeight' thing - which takes 15bn cycles - even if that work was useful - doing it synchronously seems...