commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [ognl] internal cache performance improvement
Date Mon, 06 Jun 2011 19:31:19 GMT
Great to see all that participation guys!!! And welcome to Jason between us!
Concurrency is indeed yet another key feature for internal store/cache
but IMHO a synchronized/concurrent data structure is not enough, take
a look at put( Class<?> key, T value )[1] implementation of
ClassCacheImpl: the whole block should be controlled by a concurrency
policy, not only the access to the data structure... WDYT?
The main reason of proposing a TreeMap instead of an LRU cache is
that, in the curent implementation, for each key there could be more
than one value, keeping the multiple values in a kind of inefficient
linked list, that makes inserts/searches inefficient with complexity
of O(n), with TreeMap we can decrease it to O(log n).
Anyway I'm open to suggestions the main focus is we have to improve
the cache performances, supporting concurrency :)
Thanks for your feedback, have a nice day!!!
Simo

[1] http://tinyurl.com/3qm9d7u

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Jun 6, 2011 at 6:46 PM, Maurizio Cucchiara
<mcucchiara@apache.org> wrote:
> Jason, you're right there is one OGNL context per request in struts,
> but at the time that the OGNL code was written, concurrency was taken
> into account, so at this point I think we don't have other choice
> (there could be other projects that rely on the OGNL thread-safety).
>
> On 6 June 2011 18:24, Jason Pyeron <jpyeron@pdinc.us> wrote:
>>> -----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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message