Thanks for making that video; looks great!
I’m not sure if we’re all talking about the same things here, so here’s an example of what I mean by disk vs memory caching: our new example https://examples.pyviz.org/ship_traffic/ that uses both types. First, it uses disk-based caching to Parquet files to capture the results of 10 minutes of processing a large set of CSVs, creating a Parquet file that takes 10 seconds to load. That way the full pipeline from the original source data is captured, while not having to run through it every time. Only the first time the script is run on a given filesystem does it ever need to build the Parquet file, at the cost of some disk space taken up that’s smaller than the original data. You could certainly run that in batch if you prefer.
pn.state is then used both to avoid having a user wait even that 10 seconds to load from disk, but even more importantly so that only a single copy of that dataset is needed in Python memory. If a new copy were defined for every user, the machine would quickly run out of memory, while reusing from pn.state not only speeds it up, but also avoids the memory issue.
Because these are two very different concerns, they were implemented very differently. Yes, a decorator could replace the explicit call to pn.state, which might be nice, though it wouldn’t be significantly shorter and a lot of people aren’t comfortable with decorators. It would also be nice to have some support for automatic Parquet-based caching of a columnar dataframe, but here that would maybe save a line or two of code and not be any faster. I’d be surprised if DiskCache or any other general-purpose caching solution could compete on speedup, but would be happy to be proven wrong!
I’m not sure how what you’re caching in your example relates to this; is it pickled HoloViews objects? If so that wouldn’t apply to the case in my example, where the HoloViews object isn’t weighty; it’s the underlying DataFrame that needs caching.