portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Setera, Craig" <Craig.Set...@Kingland.com>
Subject RE: Portlet Caching problem
Date Tue, 02 Apr 2002 14:39:49 GMT
My comments below...

>
> ...but initialization is not that costly these days... at least
> compared to the standard Stack implementation.

> I attach a simple comparison of creation and using a Stack based pool
> and an array based pool - very crude - but should be sufficient to
> highlight the point.

> It gives these results:

> Test1 started
> Time1 per 1000.0 new's 0.25 ms
> Time3 per 1000.0 pool lookup's 0.701 ms
> Time4 per 1000.0 array pool lookup's 0.08 ms

> [NT/Sun jdk1.3.1_02/400mhz/384MB ram]

I'm not sure I agree completely with this analysis.  I agree that it may not
be very costly to allocate and initialize those objects, but we've seen that
garbage collection costs can be very high indeed.  If Jetspeed is going to
be "industrial strength", we need to think of this in terms of weeks and
months worth of uptime.  1000's of little object allocations will cause the
garbage collector to have to run more often to keep up and increase the
overall cost of memory management.  Although I heartily agree that too much
caching can lead to problems, I don't think we can just assume it is "cheap"
to create new objects and then have GC take care of them.

> So - if you implement your own array based pool, it might be quicker
> than creation - but you need to be careful.

> Chris

I like the idea mentioned in one of the other notes about having a pool of
interchangeable objects to which the current context is attached before
execution and detached after.  That would be an excellent compromise.

Craig

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message