--- On Wed, 12/31/08, David E Jones wrote:
> > --- On Tue, 12/30/08, David E Jones
> wrote:
> >> 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 d
On Dec 31, 2008, at 8:31 AM, Adrian Crum wrote:
--- On Tue, 12/30/08, David E Jones
wrote:
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 t
--- On Tue, 12/30/08, David E Jones wrote:
> 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
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
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 ent