parametrized caching for dynamic blocks
benzen opened this issue · 6 comments
Recently I've watched https://www.youtube.com/watch?v=yhseQP52yIY
This made me think about caching strategy with html flow.
At the moment we cache the result of execution for every static template, or every static part of a dynamic template.
And that's cool.
What if we add a way to cache dynamic block ? Could we pass an optional argument to the dynamic function that would be the caching key. When evaluate a dynamic block in a template, the key would be evaluated, if it's already present in the cache, we can use it, otherwise the result of the current block would be stored in the cache.
That looks interesting. I am not sure if we need another parameter for that purpose.
In my head we only need to cache dynamic blocks too into an associative container (Map or Dictionary like) where the key is the instance model (U) passed to the template function.
Notice that the template function is a BiConsumer<DynamicHtml<U>, U> where U is the type of the model. Thus, whenever U is the same instance then the result of render() would the same and we can reuse it. It is a kind of memoization. That would improve performance.
The reason why i suggest a parameter is in order to use an external caching mechanisme, which would be a Map<String, String>
Yes It s nothing more than a good old memo. Another thing that could leed to cache key idea. How do we check that two model are the same ? Do we check same pointer?? .equals?? Given the fact that it’s not that easy to write a good equals method. Plus using a key would allow user to choose what need to be checked on the model for determining if a new computation should be done
We currently use a very simple method, based on the calls of the dynamic method. We store cache as blocks between dynamic invocations, which have an index based on their "location" between dynamic calls. For example:
Static block 1
Dynamic content
Static block 2
Dynamic content
Static block 3
Even if the same model is used on a template twice we do the same procedure, we don't cache anything regarding the models being used.
Ahh interesting. I understand that this will work very naturally for a template/view that correspond to the whole page.
But how does this play if the template in question is a small component that is reused ?
I just opened a feature request #75 and I realized this might have a relation.
Streaming very large collection of partials as small components makes all partials to be buffered and produce a Java Heap memory exception. If we limit(10) the stream, everything works flawlessly