online
online copied to clipboard
CollaboraOnline
Generic 24.04 Calc performance ticket
Well hello collectAutoStyles(), my old friend - I remember having a bash at this one, with not much success.
However, I can do something about ScDocument::GetColDefault, over here: https://gerrit.libreoffice.org/c/core/+/165346
Surprisingly unbalanced re: this UpdateCursorOverlay thing ... GetRectsAnyFor should not take that sort of time clearly - for what is ultimately only a few rectangles; looks like a substantial 2x+ perf. regression in the making.
If the spreadsheet involved had a lot of overlapping/hidden/merged cells, that would explain the time spent in GetRectsAnyFor. Unfortunately, the code involved in overlapping/hidden/merged does not look easily improved.
^^^calc 24.04 session with background save enabled^^^
^^^calc 24.04 session with background save disabled^^^
todays calc 24.04 session, background saved are merged under a single kitbgsav
I did a retest of https://github.com/CollaboraOnline/online/issues/8570#issuecomment-2031853407 with just the watchdog profiler active and did some full column copy and pastes from out typical calc testing document
The amount of break iterator loading looks odd, GetScriptTypeOfLanguage etc.
I wonder if we really need to figure out the area affected in UpdateAutoFillOverlay to send to online via LOK_CALLBACK_CELL_AUTO_FILL_AREA of it we could send an address there instead f.e
Surely we can have a one item cache, or somesuch for: SvtScriptType GetScriptTypeOfLanguage( LanguageType nLang ) =)
objdump -Wi /opt/collaboraoffice/program/libuno_sal.so.3|grep DW_AT_producer gives....
GNU C++20 12.2.1 20221121 (Red Hat 12.2.1-4) -mtune=generic -march=x86-64 -ggdb2 -O2 -std=c++20 -fvisibility=hidden -finput-charset=UTF-8 -fmessage-length=0 -fno-common -fstack-clash-protection -fcf-protection=full -fstack-protector-strong -fvisibility-inlines-hidden -fPIC -fexceptions -fno-enforce-eh-specs
and similar for coolwsd itself
Then I am guessing that o3tl::strong_int<T>:anyOf is not being compiled properly on that platform, for some reason, because it should definitely turn into just a handful of immediate instructions.
In which case we should change we should change MsLangId::getScriptType to use explicit if/then statements instead of o3tl::strong_int<T>::anyOf
Todays calc weekly session, online commit: https://github.com/CollaboraOnline/online/commits/cd9875ec core commit: https://git.libreoffice.org/core/+log/07c93a6
coolwsd.xml contains: <background_autosave desc="Allow auto-saves to occur in a forked background process where possible." type="bool" default="false">true</background_autosave>
I wonder why I don't see kitbgsav in this session
background save as expected
https://git.libreoffice.org/core/+log/421ef05 https://github.com/CollaboraOnline/online/commits/1b586a5
Hmm - that trace has 40% of the save time in the foreground - which is unexpected; we should have one non-background save at exit but ... =) Still no sign of: "WRN Failed to ensure we have just one, we have: 2| kit/Kit.cpp:1388" in the logs since the 17th which is good; prolly nailed that then.
Feedback was very positive on copy/paste today thanks @grandinj =) Digging into the 'GetOptimalHeight' code-path there I see that (oddly) there seems to be an explicit call to OutputDevice::GetTextWidth as a child of GetOptimalHeight which looks like something we could loose easily ? =) And I wonder if there are other height-not-width optimizations we could do there somehow. Anyhow - glad its feeling better :-)
there seems to be an explicit call to OutputDevice::GetTextWidth as a child of GetOptimalHeight which looks like something we could loose easily ?
Fix (I think) here: https://gerrit.libreoffice.org/c/core/+/167988
profile taken during calc testing while I wasn't present, so I'm not sure about this one, but I'll put it here anyway