You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Maurizio Cucchiara <mc...@apache.org> on 2011/10/22 03:51:02 UTC
[OGNL] Performance analysis
Hi guys,
I have just committed a new maven project, principally focused on
performance analysis of the new cache implementation (see
http://s.apache.org/YKp ).
I put it on the root of the OGNL project, please feel free to move it
on the most appropriate place.
I count to publish the test results ASAP.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OGNL] Performance analysis
Posted by Maurizio Cucchiara <mc...@apache.org>.
This is the result of the performance comparison:
Apache Commons OGNL http://s.apache.org/H1u
Legacy OGNL implementation http://s.apache.org/ih
There is a huge difference. Furthermore, looks like I need to refine
declarative method cache.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 18:23, Maurizio Cucchiara <mc...@apache.org> wrote:
> For the record, starting from now, OGNL Runtime has a new setCacheFactory
> method which allows the user to choose his preferred implementation.
>
>
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
>
>
> On 22 October 2011 12:27, Maurizio Cucchiara <mc...@apache.org> wrote:
>>
>> Apropos the idea of the maven profile is very good.
>> +1 and thank you.
>>
>> Twitter :http://www.twitter.com/m_cucchiara
>> G+ :https://plus.google.com/107903711540963855921
>> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>
>> Maurizio Cucchiara
>>
>>
>> On 22 October 2011 12:24, Maurizio Cucchiara <mc...@apache.org>
>> wrote:
>>>
>>> Sure you can, before that I should merge new branch with the current
>>> trunk.
>>> Further, FYI I have just submitted a patch for a small
>>> improvement http://issues.carrot2.org/browse/JUNITBENCH-40
>>> Twitter :http://www.twitter.com/m_cucchiara
>>> G+ :https://plus.google.com/107903711540963855921
>>> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>>
>>> Maurizio Cucchiara
>>>
>>>
>>> On 22 October 2011 12:17, Simone Tripodi <si...@apache.org>
>>> wrote:
>>>>
>>>> Hi Mau,
>>>> that for the explanation, that really helps on clarifying the graph!!!
>>>>
>>>> I have an idea about merging the tests in trunk with a profile
>>>> approach that I already submitted for the Disruptor project[1] - they
>>>> have performance/benchmark tests too - if it is fine for you I can
>>>> work on it - not today that's Rugby day, maybe tomorrow :)
>>>>
>>>> All the best and have a nice WE,
>>>> Simo
>>>>
>>>> [1] http://code.google.com/p/disruptor/issues/detail?id=2
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Sat, Oct 22, 2011 at 10:00 AM, Maurizio Cucchiara
>>>> <mc...@apache.org> wrote:
>>>> > I almost forgot there are even old vs commons comparison. Stay tuned
>>>> > :)
>>>> >
>>>> > Twitter :http://www.twitter.com/m_cucchiara
>>>> > G+ :https://plus.google.com/107903711540963855921
>>>> > Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>>> >
>>>> > Maurizio Cucchiara
>>>> >
>>>> >
>>>> >
>>>> > On 22 October 2011 09:58, Maurizio Cucchiara <mc...@apache.org>
>>>> > wrote:
>>>> >> Thank you Simo,
>>>> >> Ok, I realized after that the graph needs at least a short
>>>> >> explanation:
>>>> >> In that test I have tried to test every caches which I re-engineered.
>>>> >> In the graph you mentioned, there are depicted 3 different kind of
>>>> >> cache implementations:
>>>> >> 1. Concurrent HashMap (CHM)
>>>> >> 2. Thread-safe HashMap (HM)
>>>> >> 3. Reentrant Read Write Lock (RRWL)
>>>> >>
>>>> >> As you will notice, there are some cases where RRWL is faster, other
>>>> >> where CHM and so on.
>>>> >> So there is no yet a real winner approach, though, at very quick
>>>> >> look,
>>>> >> CHM seems to be the slower one (my guess is that it's the only
>>>> >> not-fully thread safe).
>>>> >>
>>>> >> To answer your question about projects merging, they surely could
>>>> >> work
>>>> >> under the same project, my only concern is about the execution time.
>>>> >> At the moment I'm writing the whole execution time is near 50 seconds
>>>> >> (currently the non-benchmark side take more or less 20 seconds).
>>>> >> Furthermore the benchmark tests don't give you an answer in term of
>>>> >> correctness (aside from the concurrency issues), ATM the only
>>>> >> motivation behind them is performance measurement.
>>>> >> Next time I could check the hit/miss ratio.
>>>> >> Twitter :http://www.twitter.com/m_cucchiara
>>>> >> G+ :https://plus.google.com/107903711540963855921
>>>> >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>>> >>
>>>> >> Maurizio Cucchiara
>>>> >>
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: [OGNL] Performance analysis
Posted by Maurizio Cucchiara <mc...@apache.org>.
For the record, starting from now, OGNL Runtime has a new setCacheFactory
method which allows the user to choose his preferred implementation.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 12:27, Maurizio Cucchiara <mc...@apache.org> wrote:
> Apropos the idea of the maven profile is very good.
> +1 and thank you.
>
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
>
>
> On 22 October 2011 12:24, Maurizio Cucchiara <mc...@apache.org>wrote:
>
>> Sure you can, before that I should merge new branch with the current
>> trunk.
>> Further, FYI I have just submitted a patch for a small improvement
>> http://issues.carrot2.org/browse/JUNITBENCH-40
>>
>> Twitter :http://www.twitter.com/m_cucchiara
>> G+ :https://plus.google.com/107903711540963855921
>> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>
>> Maurizio Cucchiara
>>
>>
>> On 22 October 2011 12:17, Simone Tripodi <si...@apache.org>wrote:
>>
>>> Hi Mau,
>>> that for the explanation, that really helps on clarifying the graph!!!
>>>
>>> I have an idea about merging the tests in trunk with a profile
>>> approach that I already submitted for the Disruptor project[1] - they
>>> have performance/benchmark tests too - if it is fine for you I can
>>> work on it - not today that's Rugby day, maybe tomorrow :)
>>>
>>> All the best and have a nice WE,
>>> Simo
>>>
>>> [1] http://code.google.com/p/disruptor/issues/detail?id=2
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sat, Oct 22, 2011 at 10:00 AM, Maurizio Cucchiara
>>> <mc...@apache.org> wrote:
>>> > I almost forgot there are even old vs commons comparison. Stay tuned :)
>>> >
>>> > Twitter :http://www.twitter.com/m_cucchiara
>>> > G+ :https://plus.google.com/107903711540963855921
>>> > Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>> >
>>> > Maurizio Cucchiara
>>> >
>>> >
>>> >
>>> > On 22 October 2011 09:58, Maurizio Cucchiara <mc...@apache.org>
>>> wrote:
>>> >> Thank you Simo,
>>> >> Ok, I realized after that the graph needs at least a short
>>> explanation:
>>> >> In that test I have tried to test every caches which I re-engineered.
>>> >> In the graph you mentioned, there are depicted 3 different kind of
>>> >> cache implementations:
>>> >> 1. Concurrent HashMap (CHM)
>>> >> 2. Thread-safe HashMap (HM)
>>> >> 3. Reentrant Read Write Lock (RRWL)
>>> >>
>>> >> As you will notice, there are some cases where RRWL is faster, other
>>> >> where CHM and so on.
>>> >> So there is no yet a real winner approach, though, at very quick look,
>>> >> CHM seems to be the slower one (my guess is that it's the only
>>> >> not-fully thread safe).
>>> >>
>>> >> To answer your question about projects merging, they surely could work
>>> >> under the same project, my only concern is about the execution time.
>>> >> At the moment I'm writing the whole execution time is near 50 seconds
>>> >> (currently the non-benchmark side take more or less 20 seconds).
>>> >> Furthermore the benchmark tests don't give you an answer in term of
>>> >> correctness (aside from the concurrency issues), ATM the only
>>> >> motivation behind them is performance measurement.
>>> >> Next time I could check the hit/miss ratio.
>>> >> Twitter :http://www.twitter.com/m_cucchiara
>>> >> G+ :https://plus.google.com/107903711540963855921
>>> >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>> >>
>>> >> Maurizio Cucchiara
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
Re: [OGNL] Performance analysis
Posted by Maurizio Cucchiara <mc...@apache.org>.
Apropos the idea of the maven profile is very good.
+1 and thank you.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 12:24, Maurizio Cucchiara <mc...@apache.org> wrote:
> Sure you can, before that I should merge new branch with the current trunk.
> Further, FYI I have just submitted a patch for a small improvement
> http://issues.carrot2.org/browse/JUNITBENCH-40
>
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
>
>
> On 22 October 2011 12:17, Simone Tripodi <si...@apache.org> wrote:
>
>> Hi Mau,
>> that for the explanation, that really helps on clarifying the graph!!!
>>
>> I have an idea about merging the tests in trunk with a profile
>> approach that I already submitted for the Disruptor project[1] - they
>> have performance/benchmark tests too - if it is fine for you I can
>> work on it - not today that's Rugby day, maybe tomorrow :)
>>
>> All the best and have a nice WE,
>> Simo
>>
>> [1] http://code.google.com/p/disruptor/issues/detail?id=2
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Oct 22, 2011 at 10:00 AM, Maurizio Cucchiara
>> <mc...@apache.org> wrote:
>> > I almost forgot there are even old vs commons comparison. Stay tuned :)
>> >
>> > Twitter :http://www.twitter.com/m_cucchiara
>> > G+ :https://plus.google.com/107903711540963855921
>> > Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>> >
>> > Maurizio Cucchiara
>> >
>> >
>> >
>> > On 22 October 2011 09:58, Maurizio Cucchiara <mc...@apache.org>
>> wrote:
>> >> Thank you Simo,
>> >> Ok, I realized after that the graph needs at least a short explanation:
>> >> In that test I have tried to test every caches which I re-engineered.
>> >> In the graph you mentioned, there are depicted 3 different kind of
>> >> cache implementations:
>> >> 1. Concurrent HashMap (CHM)
>> >> 2. Thread-safe HashMap (HM)
>> >> 3. Reentrant Read Write Lock (RRWL)
>> >>
>> >> As you will notice, there are some cases where RRWL is faster, other
>> >> where CHM and so on.
>> >> So there is no yet a real winner approach, though, at very quick look,
>> >> CHM seems to be the slower one (my guess is that it's the only
>> >> not-fully thread safe).
>> >>
>> >> To answer your question about projects merging, they surely could work
>> >> under the same project, my only concern is about the execution time.
>> >> At the moment I'm writing the whole execution time is near 50 seconds
>> >> (currently the non-benchmark side take more or less 20 seconds).
>> >> Furthermore the benchmark tests don't give you an answer in term of
>> >> correctness (aside from the concurrency issues), ATM the only
>> >> motivation behind them is performance measurement.
>> >> Next time I could check the hit/miss ratio.
>> >> Twitter :http://www.twitter.com/m_cucchiara
>> >> G+ :https://plus.google.com/107903711540963855921
>> >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>> >>
>> >> Maurizio Cucchiara
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
Re: [OGNL] Performance analysis
Posted by Maurizio Cucchiara <mc...@apache.org>.
Sure you can, before that I should merge new branch with the current trunk.
Further, FYI I have just submitted a patch for a small improvement
http://issues.carrot2.org/browse/JUNITBENCH-40
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 12:17, Simone Tripodi <si...@apache.org> wrote:
> Hi Mau,
> that for the explanation, that really helps on clarifying the graph!!!
>
> I have an idea about merging the tests in trunk with a profile
> approach that I already submitted for the Disruptor project[1] - they
> have performance/benchmark tests too - if it is fine for you I can
> work on it - not today that's Rugby day, maybe tomorrow :)
>
> All the best and have a nice WE,
> Simo
>
> [1] http://code.google.com/p/disruptor/issues/detail?id=2
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Oct 22, 2011 at 10:00 AM, Maurizio Cucchiara
> <mc...@apache.org> wrote:
> > I almost forgot there are even old vs commons comparison. Stay tuned :)
> >
> > Twitter :http://www.twitter.com/m_cucchiara
> > G+ :https://plus.google.com/107903711540963855921
> > Linkedin :http://www.linkedin.com/in/mauriziocucchiara
> >
> > Maurizio Cucchiara
> >
> >
> >
> > On 22 October 2011 09:58, Maurizio Cucchiara <mc...@apache.org>
> wrote:
> >> Thank you Simo,
> >> Ok, I realized after that the graph needs at least a short explanation:
> >> In that test I have tried to test every caches which I re-engineered.
> >> In the graph you mentioned, there are depicted 3 different kind of
> >> cache implementations:
> >> 1. Concurrent HashMap (CHM)
> >> 2. Thread-safe HashMap (HM)
> >> 3. Reentrant Read Write Lock (RRWL)
> >>
> >> As you will notice, there are some cases where RRWL is faster, other
> >> where CHM and so on.
> >> So there is no yet a real winner approach, though, at very quick look,
> >> CHM seems to be the slower one (my guess is that it's the only
> >> not-fully thread safe).
> >>
> >> To answer your question about projects merging, they surely could work
> >> under the same project, my only concern is about the execution time.
> >> At the moment I'm writing the whole execution time is near 50 seconds
> >> (currently the non-benchmark side take more or less 20 seconds).
> >> Furthermore the benchmark tests don't give you an answer in term of
> >> correctness (aside from the concurrency issues), ATM the only
> >> motivation behind them is performance measurement.
> >> Next time I could check the hit/miss ratio.
> >> Twitter :http://www.twitter.com/m_cucchiara
> >> G+ :https://plus.google.com/107903711540963855921
> >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
> >>
> >> Maurizio Cucchiara
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [OGNL] Performance analysis
Posted by Simone Tripodi <si...@apache.org>.
Hi Mau,
that for the explanation, that really helps on clarifying the graph!!!
I have an idea about merging the tests in trunk with a profile
approach that I already submitted for the Disruptor project[1] - they
have performance/benchmark tests too - if it is fine for you I can
work on it - not today that's Rugby day, maybe tomorrow :)
All the best and have a nice WE,
Simo
[1] http://code.google.com/p/disruptor/issues/detail?id=2
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Oct 22, 2011 at 10:00 AM, Maurizio Cucchiara
<mc...@apache.org> wrote:
> I almost forgot there are even old vs commons comparison. Stay tuned :)
>
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
>
>
>
> On 22 October 2011 09:58, Maurizio Cucchiara <mc...@apache.org> wrote:
>> Thank you Simo,
>> Ok, I realized after that the graph needs at least a short explanation:
>> In that test I have tried to test every caches which I re-engineered.
>> In the graph you mentioned, there are depicted 3 different kind of
>> cache implementations:
>> 1. Concurrent HashMap (CHM)
>> 2. Thread-safe HashMap (HM)
>> 3. Reentrant Read Write Lock (RRWL)
>>
>> As you will notice, there are some cases where RRWL is faster, other
>> where CHM and so on.
>> So there is no yet a real winner approach, though, at very quick look,
>> CHM seems to be the slower one (my guess is that it's the only
>> not-fully thread safe).
>>
>> To answer your question about projects merging, they surely could work
>> under the same project, my only concern is about the execution time.
>> At the moment I'm writing the whole execution time is near 50 seconds
>> (currently the non-benchmark side take more or less 20 seconds).
>> Furthermore the benchmark tests don't give you an answer in term of
>> correctness (aside from the concurrency issues), ATM the only
>> motivation behind them is performance measurement.
>> Next time I could check the hit/miss ratio.
>> Twitter :http://www.twitter.com/m_cucchiara
>> G+ :https://plus.google.com/107903711540963855921
>> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>
>> Maurizio Cucchiara
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OGNL] Performance analysis
Posted by Maurizio Cucchiara <mc...@apache.org>.
I almost forgot there are even old vs commons comparison. Stay tuned :)
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 22 October 2011 09:58, Maurizio Cucchiara <mc...@apache.org> wrote:
> Thank you Simo,
> Ok, I realized after that the graph needs at least a short explanation:
> In that test I have tried to test every caches which I re-engineered.
> In the graph you mentioned, there are depicted 3 different kind of
> cache implementations:
> 1. Concurrent HashMap (CHM)
> 2. Thread-safe HashMap (HM)
> 3. Reentrant Read Write Lock (RRWL)
>
> As you will notice, there are some cases where RRWL is faster, other
> where CHM and so on.
> So there is no yet a real winner approach, though, at very quick look,
> CHM seems to be the slower one (my guess is that it's the only
> not-fully thread safe).
>
> To answer your question about projects merging, they surely could work
> under the same project, my only concern is about the execution time.
> At the moment I'm writing the whole execution time is near 50 seconds
> (currently the non-benchmark side take more or less 20 seconds).
> Furthermore the benchmark tests don't give you an answer in term of
> correctness (aside from the concurrency issues), ATM the only
> motivation behind them is performance measurement.
> Next time I could check the hit/miss ratio.
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
>
Re: [OGNL] Performance analysis
Posted by Maurizio Cucchiara <mc...@apache.org>.
Thank you Simo,
Ok, I realized after that the graph needs at least a short explanation:
In that test I have tried to test every caches which I re-engineered.
In the graph you mentioned, there are depicted 3 different kind of
cache implementations:
1. Concurrent HashMap (CHM)
2. Thread-safe HashMap (HM)
3. Reentrant Read Write Lock (RRWL)
As you will notice, there are some cases where RRWL is faster, other
where CHM and so on.
So there is no yet a real winner approach, though, at very quick look,
CHM seems to be the slower one (my guess is that it's the only
not-fully thread safe).
To answer your question about projects merging, they surely could work
under the same project, my only concern is about the execution time.
At the moment I'm writing the whole execution time is near 50 seconds
(currently the non-benchmark side take more or less 20 seconds).
Furthermore the benchmark tests don't give you an answer in term of
correctness (aside from the concurrency issues), ATM the only
motivation behind them is performance measurement.
Next time I could check the hit/miss ratio.
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [OGNL] Performance analysis
Posted by Simone Tripodi <si...@apache.org>.
Hi Mau,
sorry for the silly question - I'm not familiar with JUnit benchmark -
: is there any reason why performance tests have to be separated from
the rest of the project? Can we think about merging them in the core
once reached the general/lazy consensus?
TIA, have a nice WE!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Oct 22, 2011 at 8:24 AM, Simone Tripodi
<si...@apache.org> wrote:
> Hi Mau!
> amazing work, congratulations!
> I saw results http://s.apache.org/N2u can you give me please a hint
> how to interpret the graphic?
> What do you think about comparing performances between actual
> implementation and improved implementation?
> Thanks for the extraordinary effort!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Oct 22, 2011 at 3:51 AM, Maurizio Cucchiara
> <mc...@apache.org> wrote:
>> Hi guys,
>> I have just committed a new maven project, principally focused on
>> performance analysis of the new cache implementation (see
>> http://s.apache.org/YKp ).
>> I put it on the root of the OGNL project, please feel free to move it
>> on the most appropriate place.
>> I count to publish the test results ASAP.
>>
>> Twitter :http://www.twitter.com/m_cucchiara
>> G+ :https://plus.google.com/107903711540963855921
>> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>>
>> Maurizio Cucchiara
>>
>> ---------------------------------------------------------------------
>> 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
Re: [OGNL] Performance analysis
Posted by Simone Tripodi <si...@apache.org>.
Hi Mau!
amazing work, congratulations!
I saw results http://s.apache.org/N2u can you give me please a hint
how to interpret the graphic?
What do you think about comparing performances between actual
implementation and improved implementation?
Thanks for the extraordinary effort!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Oct 22, 2011 at 3:51 AM, Maurizio Cucchiara
<mc...@apache.org> wrote:
> Hi guys,
> I have just committed a new maven project, principally focused on
> performance analysis of the new cache implementation (see
> http://s.apache.org/YKp ).
> I put it on the root of the OGNL project, please feel free to move it
> on the most appropriate place.
> I count to publish the test results ASAP.
>
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
>
> ---------------------------------------------------------------------
> 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