Goals
- Get rid of GPF tile caching where it doesn't make sense
- Allow tile-cache dedicated configurations at GPF graph node level
Background and strategic fit
GPF operators whose target tile rectangles exactly match source tile rectangles don’t require caching of tiles. In such cases, GPF’s tile-cache can waste a lot of memory and drastically slow down processing (Java GC, heap space swapping).
Caching of tiles should not take place automatically. Get even may get rid of the global GPF tile cache. Instead, we can introduce configurable tile-caches per operator / graph node. In addition, it may make sense to introduce a
TileCacheOp – a configurable operator, that simply puts its source tiles into a cache.Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Operators own tile-cache | Any tile-computing operator can have its own, configurable tile-cache. Users can configure it through graph XML or the GUI. By default, there is no tile-cache. Disposing operators after execution will definitely empty their tile-caches. | Must have | |
| 2 | TileCacheOp | TileCacheOp is a configurable, source tile-pulling operator, that simply puts its source tiles into a cache. It can be used within a graph to force tile-caching at a given point. | Optional | |
| 3 | No global tile-cache | Remove global tile-caching entirely. |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
If there is not a single tile-cache, how is it ensured that tile-caches do not grow too big? By giving each tile-cache it's own capacity? Or is there a central capacity administration? |