Feature request: Caching about hex-grid

[fananek]

It is a good point. In AI opponent programming, some kind of caching is inevitable. Especially for recursive algorithms. Even though caching wasn't originally planned to be part of the library, it could be an interesting feature.

While caching brings performance benefits, it also raises some issues. We should think a bit about:

• what shall be cached
• cache invalidation
• memory usage
• thread safety
• cache storage (memory, disk)

If we want to implement caching mechanism, I would use some more generic and reusable solution. For example, LRU/LFU algorithm sounds like a potential fit. It uses a priority queue which is already in place (used by an a-star algorithm)

Here is one more reading. Just for reference.

[mgrider]

Hi František, Yes, I see the benefits of using LRU/LFU immediately. I'll update my implementation to use one of those, and reply here when I have something to look at and/or review. Thanks!

[mgrider]

Looking a bit closer at this... it's not so simple as I'd at first imagined. The values that we'll be caching are different types of thing. I could imagine using a cache object for the neighbors example above, for instance, but then you'd need a different cache for allCellsCoordinates. I could imagine making it generic somehow, so both would be stored in the same cache, but then you've got wildly different "sized" objects stored. I'm not really sure what makes sense, at this point.

I did find an additional article with a more complete example (but pretty similar to the second reference you posted above).