online
online copied to clipboard
CollaboraOnline
generic 24.04 writer performance ticket
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
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?
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
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 (?)
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
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
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
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
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. =)
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
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)
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.
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 !
24.04.4.3snapshot git hash: 8628721 Collabora Office 24.04.4.20240629 git hash: 2657979
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)
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 =)