Chances are the size of each cache entry will be pretty small, so even
with lots of entries the amount of memory shouldn't be too large. In
general I don't like the idea of a size limited cache that uses and
LRU algorithm because there is a fair amount of overhead to maintain
the LRU list every time the cache entry is accessed (in both memory
and processing cycles).
Either way, it's easy to tune cache in production and hard to guess
about the impact of caches during development, so I'd say unless we
had some hard data that shows a memory problem and minimum performance
and memory impact from the LRU list I'd say we leave the default
settings as a wide open cache with no size limit and that doesn't have
a time limit either.
If you're really worried about it you could do something to load all
existing simple-method, screen, etc files and see what the actual size
of the cache is. This is really easy to do since if you run the
Artifact Info stuff (just go to the main page) it will load everything.
-David
On Dec 29, 2008, at 11:25 AM, Adrian Crum wrote:
Right now the expression caches have no maximum size or expire time.
The FlexibleStringExpander cache shouldn't be a problem with those
settings because the expressions are like constants - they don't
change during program execution. The maximum size on the demo server
runs around 3000-5000 entries, so I think we're safe there.
I'm concerned about the FlexibleMapAccessor cache though. Since IDs
are used to create expressions, there is a potential for that cache
to grow to tens of thousands. I think some kind of limit should be
put on that cache, but I'm not sure what they should be.
Any advice would be appreciated.
-Adrian
