commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Pyeron" <jpye...@pdinc.us>
Subject RE: [ognl] internal cache performance improvement
Date Mon, 06 Jun 2011 16:24:28 GMT
> -----Original Message-----
> From: maurizio.cucchiara@gmail.com 
> [mailto:maurizio.cucchiara@gmail.com] On Behalf Of Maurizio Cucchiara
> Sent: Monday, June 06, 2011 12:14
> To: Commons Developers List
> Subject: Re: [ognl] internal cache performance improvement
> 
> Gary hit the nail on the head, considering that OGNL usually 
> runs in a multi-thread environment like struts, concurrency is a must.

While struts2 is multi-threaded access to a given value stack should be in a
single thread, unless explicitly threaded by custom code of the OP.

> At first glance LRUMap would seem the appropriate choice (it 
> was thought for this purpose), unfortunately LRUMap is not 
> thread safe, surely we can wrap using 
> Collections#synchronizedMap, but it will always a bottlenecks.
> 
> On the other hand ConcurrentHashMap seems the appropriate 
> choice (Currently the synchronized keyword has 18 match 
> inside the OgnlRuntime class).
> 
> We could eventually consider to allow the user to decide 
> which implementation to choose.
> 
> Since I have many complex struts application in production, I 
> can do a little test.
> 
> 
> 
> On 6 June 2011 16:55, Gary Gregory <garydgregory@gmail.com> wrote:
> > Does concurrency need to be taken into account for the 
> cache? If so, 
> > you need to consider how access to the cache will be 
> synchronized. An 
> > intrinsic lock? A ConcurrentHashMap? and so on.
> >
> > Gary
> >
> > On Mon, Jun 6, 2011 at 2:36 AM, Simone Tripodi 
> <simonetripodi@apache.org>wrote:
> >
> >> Hi all OGNL folks,
> >> my today's topic is about internal cache, that can be IMHO 
> improved 
> >> in therms of performance; its implementation is a multi-value map 
> >> alike, based on a fixed-size array, a function is applied 
> to each key 
> >> to calculate the array index, each array element is a 
> Collection of 
> >> element.
> >> Even if getting the list of element related to a general 
> key 'k' has 
> >> complexity of O(1), which is fine, insert/search 
> operations are not 
> >> the best because their complexity is O(m) where m is the 
> size of list 
> >> related to the key.
> >> Follow below my proposal: there's no need to reinvent the 
> wheel, so 
> >> the array implementation can be replaced with the already provided 
> >> HashMap, where each map value is a simple implementation 
> of balanced 
> >> binary heap (AFAIK commons-collections already provides an 
> >> implementation), that allows us reducing insert/search 
> complexity to 
> >> O(log m).
> >> WDYT? Is is a worth or trivial added value? I know that 
> maybe cache 
> >> dimension is relatively small, but linear search sounds too basic, 
> >> isn't it?
> >> Looking forward to your feedbacks, have a nice day, Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://www.99soft.org/
> >>
> >> 
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message