Speed up fetching of WebDAV folder listing #31160
Conversation
Before this patch, the WebDAV requests was done once all the scripts are executed and that the DOMContentLoaded is executed. This is an issue because it takes a long time for all the scripts to be run (~900ms). Futhermore, once the request is done the CPU is idle because there is no script anymore to fetch and it's just waiting for the response. This patch makes the script do the WebDAV when executing the script instead of when DOMContentLoaded is executed. This has the advantage that during the WebDAV requests, the browser is not idle but continue executing the other scripts (thanks to the async IO). End result: the file listing is displayed 100ms earlier This also makes sure that the files_sharing scripts are executed earlier than the files scripts as they have event listeners on the files apps. Signed-off-by: Carl Schwan <carl@carlschwan.eu>
|
This will need a bit more thinking. We need to execute |
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
|
Haven't tested yet, but this might have potential to break apps that register a plugin on the file list to extend the properties fetched during propfind (e.g. groupfolders/files_lock) if the registration then happens too late. https://github.com/search?q=org%3Anextcloud+addFileInfoParser&type=code would be a list of things we should check at least. |
|
I didn't test other apps but at least the groupfolders ACL in the sidebar still works |
|
Tested a bunch and they indeed do not seem to be working anymore:
Mainly the hot-patching of the files client that is done in those apps does not happen anymore before the file list issues the propfind on the initial load, so this works again on the second propfind, just the first is broken :/ |
I suppose this will need to define in php, that parameter will need to be fetched if I understand correctly. Unfortunately this means adding new api (topic: file info api) and something not backportable |
| @@ -398,10 +393,4 @@ | |||
| }; | |||
| })(); | |||
|
|
|||
| window.addEventListener('DOMContentLoaded', function() { | |||
| // wait for other apps/extensions to register their event handlers and file actions | |||
There was a problem hiding this comment.
seems you discarded this logic
now, this was there for apps that still register their file actions using the global FileActions object instead of the namespaces one. Not sure how many such apps still exist nowadays.
|
if we go this way I'd advise to not backport because this could break apps that are using the old approach for registering file actions. as far as I remember there was a potential loading order issue that if an app's JS code is loaded and running before the files app is initialized, then it wouldn't have access to the global it all depends how apps are written. might be good to retest with a few apps that register file actions and those that hook into the files app also |
|
ideal would be to have the file list array separated from the FileList view class this is what we'd do anyway once porting the file list to Vue |
|
Outdated with new Files app |
Before this patch, the WebDAV requests were done once all the scripts are
executed and the DOMContentLoaded events is triggered. This is an issue
because it takes a long time for all the scripts to be run (~900ms).
Furthermore, once the request is done the CPU is idle because there is no
script anymore to fetch and it's just waiting for the response.
This patch makes the script do the WebDAV when executing the script
instead of when DOMContentLoaded is executed. This has the advantage
that during the WebDAV requests, the browser is not idle but continue
executing the other scripts (thanks to the async IO).
End result: the file listing is displayed ~100-200ms earlier
This also makes sure that the files_sharing scripts are executed earlier
than the files scripts as they have event listeners on the files apps.
Chromium profiler result before this change:
Chromium profiler results after this change:
Todos: