CollaboraOnline
Generic 25.04 Calc performance ticket
Today's staging-perf calc profile. 13-03-2025:
First profile:
Second profile:
Third profile:
Fourth profile:
cc: @mmeeks @timar @caolanm @eszkadev
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.
Today's staging-perf calc profile. 18-03-2025:
First profile:
Second profile:
Today, among other things we tested: image insertion and saving several times.
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 :-)
Today's staging-perf calc profile. 20-03-2025.
We had two test sessions today, so one profile for each.
COOL Weekly profile:
Collaborative test session:
Today's staging-perf calc profile from collaborative test session. 21-03-2025.
First profile:
Second profile:
Today's staging-perf calc profile from collaborative test session. 25-03-2025.
We tested two different calc files. There was a server disconnect while testing the second calc file.
Version:
COOLWSD version: 25.04.0.0(git hash: dc89e06403 (E)) LOKit version: Collabora Office 25.04.0.1(git hash: dc6e50ff7d) WOPI host: nextcloud 31.0.2.1 - richdocuments 8.6.3
First file:
Second file:
Today's staging-perf calc profile from COOL Weekly. 27-03-2025.
There were issues with dark mode, rendering, and pdf export.
COOLWSD version: 25.04.0.0(git hash: 0006699960 (E)) LOKit version: Collabora Office 25.04.0.1(git hash: e871dc2bb1)
Today's staging-perf calc profile from collaborative test session. 02-04-2025.
COOLWSD version: 25.04.0.0(git hash: 828a24a40f (E)) LOKit version: Collabora Office 25.04.0.1(git hash: 3067675b5b)
Today's staging-perf calc profile from COOL Weekly. 10-04-2025.
COOLWSD version: 25.04.0.0(git hash: ed9d5413a2 (E)) LOKit version: Collabora Office 25.04.0.1(git hash: bf389ede6d) WOPI host: nextcloud 31.0.3.1 - richdocuments 8.6.4
First profile:
Second profile:
Today's staging-perf calc profile from collaborative test session. 22-04-2025.
COOLWSD version: 25.04.0.3(git hash: b2ad28b546 (E)) LOKit version: Collabora Office 25.04.0.3(git hash: e138a0c430)
Today's staging-perf calc profile from CoolWeekly. 24-04-2025.
COOLWSD version: 25.04.0.3(git hash: 84302130fb (E)) LOKit version: Collabora Office 25.04.0.3(git hash: 636de9160a)
There were two crashes, but not related to calc itself.
First Profile:
Second profile:
Third profile:
Today's staging-perf calc profile from Collaborative test session . 30-04-2025.
COOLWSD version: 25.04.1.1(git hash: 5e1ee4029a (E)) LOKit version: Collabora Office 25.04.0.3(git hash: 2573db10d2)
Today's staging-perf calc profile from COOL Weekly. 01-05-2025
COOLWSD version: 25.04.1.1(git hash: 42687529d9 (E)) LOKit version: Collabora Office 25.04.0.3(git hash: d6b8e20c9c)
First profile:
Second profile:
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. @grandinj if you're interested here - we badly need a sensible hierarchical cache 'dirty'ing method that we can use to build and discard caches that answer eg. "what is the real left/right extent of cells on this row " =) etc.
From today's collaborative test session on staging perf 07-05-25:
COOLWSD version: 25.04.1.1(git hash: 4189a0ad3f (E)) LOKit version: Collabora Office 25.04.1.1(git hash: a865c65727)
First profile:
Second profile
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 being able to fork - will need to dig that out - it's not obvious what that could be.
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 being able to fork - will need to dig that out - it's not obvious what that could be.
Depending on how close this is to master, I added a background thread thing to GC drawinglayer cached objects. specifically a class called BufferedDecompositionFlusher
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 see what new thing is there :-) Even more ideally as a 31337 hack we should send a SIGUSR2 (or whatever we use to signal 'do a stack trace') to that thread as/when we are blocked by an extra thread from bgsaving I guess.
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 join'
-- No entries --
etc. so perhaps a red-herring. Could it be people doing 'Download-As' repeatedly which is IIRC still synchronous.
Today's staging-perf calc profile from CoolWeekly. 08-05-2025.
COOLWSD version: 25.04.1.1(git hash: b376acae72 (E)) LOKit version: Collabora Office 25.04.1.1(git hash: 6e3a939815)
First profile:
Second profile:
Today's staging-perf calc profile from Collaborative test session. 12-05-2025.
Today's staging-perf calc profile from COOL Weekly. 15-05-2025.
COOLWSD version: 25.04.2.1(git hash: 0968141f2c (E)) LOKit version: Collabora Office 25.04.2.1(git hash: 362b544a13)
@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 process: so sending selection at idle would be rather more helpful than in SelMouseMove I guess.
The IsEmptyCellText cost is a symptom of people extending the sheet data area to the full width - usually by pasting through a row - and then rendering large areas of empty cells. We need to get better at caching and invalidating that cache in the core cell mutation methods of ScColumn and ScTable.
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 deeply unhelpful - it should be a low priority background task I expect - ideally also one that is invalidation-light :-)
From today's collaborative test session 20-05-25
COOLWSD version: 25.04.2.1(git hash: https://github.com/CollaboraOnline/online/commit/601130d3f94c3ae1d4c268e1e84d007ba27f08a8 (E)) LOKit version: Collabora Office 25.04.2.1(git hash: 80139ffdd6)
CC: @timur-g @Ezinnem
From today's COOL Weekly 22-05-25
COOLWSD version: 25.04.2.1(git hash: 224367de9a (E)) LOKit version: Collabora Office 25.04.2.1(git hash: 62f094380d)
First Profile:
Second profile:
From today's Collaborative test session 27-05-25,
CALC
COOLWSD version: 25.04.2.1(git hash: https://github.com/CollaboraOnline/online/commit/16fa3ede1810867c87a68ccced7f757203013caf (E)) LOKit version: Collabora Office 25.04.2.1(git hash: ad2782a447)
From today's COOL Weekly 29-05-25
COOLWSD version: 25.04.2.2(git hash: 8e56e894c3 (E)) LOKit version: Collabora Office 25.04.2.2(git hash: b05614d687)
First profile:
Second profile