Project

General

Profile

Workbench responsiveness » History » Version 1

Tom Clegg, 09/04/2024 07:16 PM

1 1 Tom Clegg
h1. Workbench responsiveness
2
3
Notes on Workbench performance/caching from brainstorming meeting 2024-09-04
4
5
* Currently the store is our cache, and it caches individual objects (key is UUID)
6
** When opening an object in a new tab, it might be easy to use postMessage to pass the current store contents to the new tab to speed things up
7
** Each data explorer has its own store key, so (for example) we store "page of project listing" rather than "page 1 of project A listing with filters xyz"
8
** We could start using the store to cache list responses (key is request URL with all params?)
9
** We could pre-fetch and cache the next page of a listing before the user even clicks the "next page" button
10
** Currently the store grows indefinitely, so if we use it more, we'll need an eviction strategy
11
** We could save timestamps in the store so we don't re-fetch on every page view when navigating back and forth quickly
12
* In theory, web workers could implement an HTTP cache shared between tabs
13
** Lisa has some experience with web workers that didn't go well (ended up bailing), but would be willing to look into it again
14
** Tom hasn't tried it but remembers reading that the mechanics of installing/updating the web worker code is non-trivial
15
** Would presumably be disabled for most of the test suite
16
* Collection file listings are slow because XML decoding is slow, and we don't use the store to cache them
17
** We could start caching the (decoded) listings in the store
18
** We could add a JSON format option to keep-web to skip XML encoding+decoding entirely (Workbench doesn't need to support arbitrary WebDAV servers, after all)