You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To optimize performance, especially when adding new channels, I think we should settle on a (few) caching solution(s), without assuming that the browser will handle this. I think there are two paths forward: a loader cache and a layers cache. I'll give an outline of where I see a solution in each.
One option would be to do something on the layers:
The TileLayer comes pre-loaded with a cache that works very well and can be set via a parameter, configurable both for number of images and size in bytes. I think we should fine tune this.
Furthermore, I think something similar, using a (potential) combination of more advanced state management (for adding new channels) and an actual explicit cache (for removing channels from state and then adding them back later), in the StaticImageLayer is possible. geotiffjs already has a built-in caching mechanism, which we would likely want to turn off as well, as anything that zarr has or will implement, so we are not duplicating our data stores.
Potential Steps:
Turn off the geotiffjs cache as well as any cache zarr may have.
Settle on an out-of-the-box cache size/strategy for the TileLayer.
Implement an explicit cache and/or more advanced state management for the StaticImageLayer.
Another option would be to have something on the loaders:
Basically, we would maintain a Map() on the loader of all made requests to their outputs and diff the current request's selection against what is in the map returning whatever is cached and HTTP-requesting whatever is not. The main hurdle here that I see is settling on an ID mechanism for the cache that is unified across both static and tiled imagery.
To my mind, the best solution is perhaps a mix of the two: optimize the tile cache inherited from the TileLayer (since it provides smoother visuals as well) and also implement a loader cache. I think this will take some experimenting to get right but I want to get the ball rolling. My idea here is to basically have one request for data per channel only once, using the cache the rest of the time. Perhaps this isn't feasible, but it seems worth striving for.
Thoughts?
The text was updated successfully, but these errors were encountered:
ilan-gold
changed the title
RFC: Settle on a consistent caching mechanism
RFC: Settle on a "consistent" caching mechanism
May 3, 2020
To optimize performance, especially when adding new channels, I think we should settle on a (few) caching solution(s), without assuming that the browser will handle this. I think there are two paths forward: a loader cache and a layers cache. I'll give an outline of where I see a solution in each.
One option would be to do something on the layers:
The
TileLayer
comes pre-loaded with a cache that works very well and can be set via a parameter, configurable both for number of images and size in bytes. I think we should fine tune this.Furthermore, I think something similar, using a (potential) combination of more advanced state management (for adding new channels) and an actual explicit cache (for removing channels from state and then adding them back later), in the
StaticImageLayer
is possible.geotiffjs
already has a built-in caching mechanism, which we would likely want to turn off as well, as anything thatzarr
has or will implement, so we are not duplicating our data stores.Potential Steps:
geotiffjs
cache as well as any cachezarr
may have.TileLayer
.StaticImageLayer
.Another option would be to have something on the loaders:
Basically, we would maintain a
Map()
on the loader of all made requests to their outputs and diff the current request's selection against what is in the map returning whatever is cached and HTTP-requesting whatever is not. The main hurdle here that I see is settling on an ID mechanism for the cache that is unified across both static and tiled imagery.To my mind, the best solution is perhaps a mix of the two: optimize the tile cache inherited from the
TileLayer
(since it provides smoother visuals as well) and also implement a loader cache. I think this will take some experimenting to get right but I want to get the ball rolling. My idea here is to basically have one request for data per channel only once, using the cache the rest of the time. Perhaps this isn't feasible, but it seems worth striving for.Thoughts?
The text was updated successfully, but these errors were encountered: