generic 24.04 writer performance ticket

[caolanm]

Writer 24.04 flamegraphs

[caolanm]

24.04 writer profile where we endured a slowdown after (possibly) selecting all text in 72 page and changing the font size.

Showing a cursor seems to have found some case where the notorious solveCrossovers gets called, odd

[grandinj]

Showing a cursor seems to have found some case where the notorious solveCrossovers gets called, odd

That means that we have a selection overlay which (a) consists or more than one rectangle and (b) has a border, in which case we try and convert it into a "nicer" overlay polygon with a single continuous border.

Possibly we should just do what other software does and have multiple rectangles for that case, even if it means the borders don't look quite as nice.

Or maybe get alg to write us an optimised variant of that solveCrossovers() which only handles combining rectangles?

[grandinj]

Or maybe get alg to write us an optimised variant of that solveCrossovers() which only handles combining rectangles?

Some interesting suggestions here, for such an algorithm: https://stackoverflow.com/questions/13746284/merging-multiple-adjacent-rectangles-into-one-polygon

[mmeeks]

The curious thing is that we split that polygon per-page; I wonder if by pushing that knowledge from up the stack down to here we could save trying to do 72 pages worth of pointless intersection, and just do that a page at a time (?) =) or perhaps we already do that (?)

[grandinj]

No, it doesn't look like we pass down the selection as per-page information, it's just one big vector of rectangles.

Anyhow, WIP attempt at speeding this up at https://gerrit.libreoffice.org/c/core/+/165752

[caolanm]

Today's typical small meeting document

[juliushaertl]

As @pedropintosilva suggested I did a few screen recordings (more to come still) now also for 24.04 with some smoke testing for performance issues I've noticed that I'll just leave here as discussed with him. As I imagine the document used might be relevant, I used the ebooks from https://books.libreoffice.org/en/ as odt:

Note I'm also happy to file those individually if that makes more sense to you

File loading

Empty white pages shown for a long time, also the UI is only slowly changing its state

writer-slow-loading.webm

Initial rendering when scrolling

Following the previous loading scrolling down also takes a decent time to show the page content (might be related to the larger ToC), though this only happens once initially

writer-slow-page-scrolling.webm

Toggling formatting marks is slow

writer-slow-toggle-formatting-marks.webm

Enabling page headers and typing is slow

writer-header-slow.webm

Scrolling through a document

I see that those tiles need to get rendered and transferred of course, just thought as a user this might cause the impression of performance issues, maybe some smart preloading of the next tiles could be done (or improved if already in place)

writer-scrolling-maybe-preload.webm

[mmeeks]

Might be interesting to work on this particular 600+ page book during testing to see if we can work out what is going on; I expect it is packed with large numbers of interesting features, charts etc. =)

[caolanm]

Todays 24.04 writer session, while under extra bgsave load

[caolanm]

Todays writer 24.04 session

[caolanm]

Todays writer 24.04 session

[caolanm]

today's writer 24.04 session with bgsaves merged together

[caolanm]

today's scheduled call writer profile

[caolanm]

todays regular call writer profile

[caolanm]

todays regular call writer profile

[caolanm]

todays regular call writer profile

[caolanm]

todays regular writer profile, GetAccessibleDescription seems to be falling back to querying "local" help for HelpText which isn't even included (--without-help on those builds) so I can at the least make vcl conditionally not even bother if built without local help support

[caolanm]

https://gerrit.libreoffice.org/c/core/+/168447 for that idea

[caolanm]

todays writer call on staging-perf

[mmeeks]

Interesting to see so much time in lcl_DrawLineForWrongListData - I assume drawing wiggly underlined data is back in the profile at ~25% of rendering cost; oddly I thought we had a bitmap cache for that which massively accelerated this for spell checking @grandinj any idea if there is an extra path here, or perhaps the cache is too small and needs to scale with the # of differently sized and colored views (we were stressing that today I think)

[grandinj]

Interesting to see so much time in lcl_DrawLineForWrongListData

The cache was added in commit 0759191e6923945469bc426b2c322ddeade12e09, and it 10 items big. The item key is { lineHeight, lineColor}.

Do you think you had more than 10 combinations of that? If so, we can just change that to cache size to 100 for the LOK case.

[mmeeks]

Quite probably we should size the cache based on the number of distinct views; I guess we want a comphelper/lok.hxx method that lets us know how many distinct views there are and (ultimately) get this to be what we call normalized views (ie. that share the same zoom/rendering attributes) - so that we don't over-enlarge the cache and have some sharing.

And then use that to do 5x the number of views or whatever (?) =) Would be grea tif you can look at that Noel !

[caolanm]

24.04.4.3snapshot git hash: 8628721 Collabora Office 24.04.4.20240629 git hash: 2657979

[caolanm]

24.04.4.2 git hash: 20b6b94a Collabora Office 24.04.4.2 git hash: 2d2c24d (confusingly this one is master I think and the above is 24.04 branch)

[mmeeks]

Hmm - the writer profiles has a lot of deltas in it - which looks unhealthy; I've also started to see the horror of full-document invalidations per-keystroke creeping back into collaborative editing sessions; it would be extremely good to have a desktop/source/lib/init.cxx lok_sample() type method that calls your watchdog trigger system-call on Linux, and that is used whenever a large area - or EMPTY invalidation is emitted - ideally from the core itself and not later from the CallbackFoo queue logic - so we can see where these come from =)

[caolanm]

todays regular weekly meeting writer profile

[caolanm]

todays collaborative session inserting images into writer

[caolanm]

dysfunctional 24.04.5.2 writer document hang

[caolanm]

Underwhelming experience with 24.04.4.5 grinding over bitmaps

[caolanm]

Todays weekly scheduled cool meeting writer profile

[caolanm]

collaborative writer testing

[caolanm]

Today's writer profile

[caolanm]

Todays staging writer profile

[mmeeks]

Still amusing to see PaintBorderAndShadow taking chunks of server time - when we have the data to render that better on the client side - and IIRC already do. I forget if we filed a perf ticket about that somewhere here =) Against that - it's nice to to have to worry about parallelizing document thumbnail saving as 50% of save-time anymore due to bgsave =) doc_setView is taking quite some time. I wonder if sorting by view - while injecting input events would help somewhat there.

[caolanm]

Todays staging-perf writer profile

[caolanm]

Today's staging-perf writer profile

[caolanm]

Above is only a few minutes long before closed with "closeReason: documentconflict Szűcs Attila" and replaced with this longer session

[caolanm]

A writer session pasting from mattermost where a UUIInteraction dialog requesting login/password for the remote graphic appears

[caolanm]

Weekly COOL Meeting writer profile

[caolanm]

Weekly COOL Meeting writer profile

[caolanm]

uneventful writer perf-staging profile from todays meeting

[caolanm]

Writer document, with a sample paste from mattermost causing the handleAuthenticationRequest dialog

[caolanm]

https://github.com/CollaboraOnline/online/issues/9956 is related to this paste issue I think

[caolanm]

Today's writer profile

[mmeeks]

Interesting profile; the ratio of RenderTiles in threads vs. in the main process is slightly suspicious - there is rather more going on there than we might expect perhaps ? =)