> -----Original Message----- > From: maurizio.cucchi...@gmail.com > [mailto:maurizio.cucchi...@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 <garydgreg...@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 > <simonetrip...@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-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
