Class VFXCellsCache<T,C extends VFXCell<T>>

java.lang.Object
io.github.palexdev.virtualizedfx.utils.VFXCellsCache<T,C>
public class VFXCellsCache<T,C extends VFXCell<T>> extends Object
Simple cache implementation for virtualized containers that produce cells of type VFXCell. Cells are stored in a CellsQueue, a special extension of LinkedList. The cache can be limited in the maximum number of cells to keep by setting its capacity, see VFXList.cacheCapacityProperty(). Cells won't be added if the capacity is reached and will be disposed immediately instead.

Aside from the typical functions of a cache (take/store), you are also allowed to 'populate' it at will, see populate().

Note however that to generate cells, the cache must know the function to produce them. The function must be the same used by the container, therefore, it's set by the container itself.

This is mostly useful to 'pre-populate' it, filling the cache before the container is even laid out, so that at init cells are already built and just need to be updated.

Beware, in order for this to work, the cells you are using must allow null items!

Dev Notes

I often thought about optimizing the cache by using a Map instead of a Queue to store the cached cells. However, doing so poses a variety of issues that make such an improvement not possible.

Pros

The enhancement would make the cache more efficient in theory because when a cell is de-cached it could be extracted by the needed item. Which means that if a cell was previously built for that item, the only update needed would be the index. The current implementation, polls the first available cell in the cache and updates both the item and the index.

Cons

- The populate() method could not work because the cells are produced with null items. So, these cells would require a separate collection. This would also make controlling the cache capacity a bit harder, as well as add and poll operations.

- The mapping [Item -> VFXCell] raises the problem of updating the cache when the items list changes. If an item is removed from the list, and a mapping is present in the cache, then it becomes invalid. Which means that the cell associated with that item would need to be disposed or moved to the other collection.

- T items come from "outside". In this new version of VirtualizedFX, to simplify the handling of changes in the items' list, mappings of type [Item -> VFXCell] are used in the state. But to avoid memory leaks, old maps are always cleaned, so that there is not any reference to old items. So, again, we would have to manage this aspect too for the cache.

Ultimately, the number of cons and the implementation complexity they pose make me think that the refactor would not be worth the effort. Especially considering that I have no empiric proof that it would be more efficient, JMH tests would be required, which is even more work and thus adds up to the cons.

  • Constructor Details

    • VFXCellsCache

      public VFXCellsCache(CellFactory<T,C> cellFactory)

    • VFXCellsCache

      public VFXCellsCache(CellFactory<T,C> cellFactory, int capacity)

  • Method Details