Slow loading state of file list

[kulmann]

Steps to reproduce

1. Navigate into a folder with 1000 files

Expected behaviour

When the network request (propfind) is done the file list is visible and usable in a timely manner.

Actual behaviour

The file list takes ages to render and even a little bit longer until the first interaction is possible (e.g. context menu).

Action items / hints

• check if loading previews blocks the UI (especially on scroll)
• analyse what exactly takes so long after the initial propfind is done. we thought that the lazy loading of cells would improve render speed a lot, but it did not
• There seem to be a lot of events, causing (partial) re-renders (-> have a look at events in vue dev tools)
• Collecting all the different tr/td attributes in OcTable is apparently not cached, this might be a huge issue

[kulmann]

Probably best to solve this in a narrow scope: owncloud/owncloud-design-system#1867

[pascalwengerter]

I've done some digging and also opened #7056 (which doesn't even seem to work now, apparently caching made it seem like it worked the other day), pretty convinced that while the OcTable/ResourceTable rendering adjustments do have some positive impact the real culprint seems to be the loadIndicators logic. From how I understood it, we

• load resources (network request)
• save resources to store (triggers Vue rendering)
• purge parts of the store related to share status of resources (triggers Vue rendering)
• load indicators (network request)
• save indicators to store by running a for-loop over all available resource (triggers Vue rendering)

There's a comment hinting at room for performance improvements by changing that logic, but there's a lower-hanging fruit from what I've seen:

We don't seem to run into the continue condition when checking whether we need to actually modify the store per resource by saving indicators to it - this leads to an insane amount of store commits that ultimately don't actually change the resource, see screenshot below. Every thin line is another couple of milliseconds, adding up rather quickly due to all the implications of modifying the store

Ideally for now, we can reduce the continue-logic to if (!indicators.length) { continue } to not modify the store if there is no shareIndicators to be added/loaded

We could also discuss if we can request the share-status with the initial resource request from the backend maybe? That'd be the most performant solution I can imagine

[kulmann]

classic ui does it the right way already: using the "shareTypes" field from the propfind (= direct shares) and then doing an ocs shares request for each parent folder up to the root (= indirect shares). We should adopt the same.

[kulmann]

Apart from that I'm still convinced that the rendering itself is slow. See the ODS PR for lazy loaded icons documentation page using the OcTable without any reactivity in the data. 😅

[pascalwengerter]

Apart from that I'm still convinced that the rendering itself is slow. See the ODS PR for lazy loaded icons documentation page using the OcTable without any reactivity in the data. 😅

Played around by replacing the table subcomponents with (mostly) canonical HTML tags and while it looses the shimmering lazy-loading, rendering then happens _ultra_fast. Might also help that I removed the 6*2275 onclick-listeners on the OcIcon instances 😄

[kulmann]

Apart from that I'm still convinced that the rendering itself is slow. See the ODS PR for lazy loaded icons documentation page using the OcTable without any reactivity in the data. 😅

Played around by replacing the table subcomponents with (mostly) canonical HTML tags and while it looses the shimmering lazy-loading, rendering then happens _ultra_fast. Might also help that I removed the 6*2275 onclick-listeners on the OcIcon instances 😄

[pascalwengerter]

Apart from that I'm still convinced that the rendering itself is slow. See the ODS PR for lazy loaded icons documentation page using the OcTable without any reactivity in the data. 😅

Played around by replacing the table subcomponents with (mostly) canonical HTML tags and while it looses the shimmering lazy-loading, rendering then happens _ultra_fast. Might also help that I removed the 6*2275 onclick-listeners on the OcIcon instances 😄

owncloud/owncloud-design-system@6143188 not part of master since it's a breaking change

[tbsbdr]

@pascalwengerter sounds like promising research ✨ Where is this currently on your prio list? I would be happy to provide a fast fileslisting for users as it affects the experience all the time.

CC @d7oc reading the thread above doesn't sound like what we discussed but maybe I'm wrong.

[tbsbdr]

Where is this currently on your prio list?

ping @pascalwengerter

[tbsbdr]

wohaa, really good progress again!

• for 1.000 (and even 2.000 files) scrolling feels already fast enough. would still need some testing, buts fast enough on my machine I would say. awesome!
• the time after the login screen until I see the first file (with 1.000 items-pagination) takes ~5.6 seconds on my side which feels already to long.

... just sharing my experience

Screenshot.000048.mp4

[tbsbdr]

as remedy until we do the vue3 update: lets remove the pagination options:

• 1000
• all

[JammingBen]

as remedy until we do the vue3 update: lets remove the pagination options:

• 1000
• all

#7597

How do further progress with this ticket? While this is still "an open thing", I think we're good in regards to GA.

[kulmann]

@JammingBen can be closed when #7597 is merged. The vue3 update is its own issue and after that's done we can create a new ticket for performance improvements as needed.