portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Portlet Caching problem
Date Tue, 02 Apr 2002 17:29:08 GMT
Chris Kimpton wrote:

>--- Santiago Gala <sgala@hisitech.com> wrote:
>>Glenn Golden wrote:
>>(...snip...) See comments by Raphael below
>>>Also noticed that the PortletWrapper objects are not cached, and
>>are being
>>>created and used once and thrown away for each wrapped portlet. 
>>The PortletWrappers are quite lightweight objects, which do not
>>need a 
>>costly initialization.
>...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]
>So - if you implement your own array based pool, it might be quicker
>than creation - but you need to be careful.

My point was not about generic simple objects. I was trying to make the 
point that the PortletWrapper is not that bad if it is not cached. After 
all, its instantiation is a couple of asignments.

My point is that a RSSPortlet, which must get, parse, and transform XML 
files with XSLT templates, is worth caching, while other small objects, 
like the PortletWrapper, should better be pooled or just instantiated.

As you have pointed, the worth of pooling will depend a lot of 
implementation, and kind of VM in use (specially the garbage collector). 
So, we should be very careful before optimizing prematurely. On the 
other side, having to wait for several RSS channels to initialize on 
each request is definitely not feasible.

>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

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

View raw message