On Fri, Jul 8, 2011 at 12:44 PM, Dan Berindei dan.berin...@gmail.com wrote:
It's interesting that in the writeOnMiss test the new LRU performance
dropped when I increased the concurrency level from 32 to 128. I think
it might be because the eviction.thresholdExpired() check in
Amazing, congratulations Vladimir Dan!
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Yeah, nice work guys. :)
On 11 Jul 2011, at 17:10, Sanne Grinovero wrote:
Amazing, congratulations Vladimir Dan!
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik
On 11-07-08 5:44 AM, Dan Berindei wrote:
I haven't run the tests with concurrency level 512, as the total
number of threads is only 100, but I suspect the old LRU still won't
catch up with the new LRU's performance.
It's interesting that in the writeOnMiss test the new LRU performance
On Mon, Jul 11, 2011 at 7:29 PM, Vladimir Blagojevic
vblag...@redhat.com wrote:
On 11-07-08 5:44 AM, Dan Berindei wrote:
I haven't run the tests with concurrency level 512, as the total
number of threads is only 100, but I suspect the old LRU still won't
catch up with the new LRU's
On Fri, Jul 8, 2011 at 2:53 AM, Dan Berindei dan.berin...@gmail.com wrote:
I've updated pull #414
(https://github.com/infinispan/infinispan/pull/414) to work on top of
Vladimir's pull request, in case you want to have a look. You might
want to adjust the number of keys and/or disable some of
Dan,
Great work, why not update my forked tree
https://github.com/vblagoje/infinispan/tree/t_bchm with your work as
explained in section Multi-step coordination between developers using
forked repositories from
https://docs.jboss.org/author/display/ISPN/Contributing+-+Source+Control
And then
On 11-07-07 6:21 AM, Manik Surtani wrote:
I think we leave the old LRU as LRU_OLD and mark it as deprecated.
Vladimir, does this apply to LIRS as well?
No, not LIRS, this was LRU optimization overlooked from the beginning :-)
___
infinispan-dev
On Thu, Jul 7, 2011 at 1:21 PM, Manik Surtani ma...@jboss.org wrote:
I think we leave the old LRU as LRU_OLD and mark it as deprecated.
I for one am against keeping the old policy around, as the new LRU
policy implements exactly the same algorithm only in O(1) instead of
O(n).
It would have made
Hey,
Ok I've issued a pull request. Please review it
https://github.com/infinispan/infinispan/pull/418
I am very happy with performance increase observed in new LRU. It
significantly beats synchronized Map and performance is very close to
ConcurrentHashMap itself.
I ran tests overnight for 12
Awesome!
Are you really sure about eradicating the old implementation?
Cheers,
Sanne
On 6 Jul 2011 19:39, Vladimir Blagojevic vblag...@redhat.com wrote:
Hey,
Ok I've issued a pull request. Please review it
https://github.com/infinispan/infinispan/pull/418
I am very happy with performance
No :-) We can leave it, it all depends on how many more CR cycles we
have before Final release to field test new LRU!
On 11-07-06 2:46 PM, Sanne Grinovero wrote:
Awesome!
Are you really sure about eradicating the old implementation?
Cheers,
Sanne
On 6 Jul 2011 19:39, Vladimir Blagojevic
:
From: Vladimir Blagojevic vblag...@redhat.com
Subject: [infinispan-dev] Faster LRU
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Date: Tuesday, July 5, 2011, 11:23 AM
Hey guys,
In the past few days I've look around how to squeeze every bit of
performance out of BCHM and particularly our
On Tue, Jul 5, 2011 at 7:23 PM, Vladimir Blagojevic vblag...@redhat.com wrote:
Hey guys,
In the past few days I've look around how to squeeze every bit of
performance out of BCHM and particularly our LRU impl. What I did not
like about current LRU is that a search for an element in the queue
On 11-07-05 12:47 PM, Alex Kluge wrote:
Hi,
I have a completely in-line limit on the cache entries built on a
clock cache that is an approximation to an LRU cache, and is extremely
fast (O(1)). It is not a strick LRU, but chooses a not recently used
item for removal. I'll provide some more
On Tue, Jul 5, 2011 at 7:47 PM, Alex Kluge java_kl...@yahoo.com wrote:
Hi,
I have a completely in-line limit on the cache entries built on a clock
cache that is an approximation to an LRU cache, and is extremely fast
(O(1)). It is not a strick LRU, but chooses a not recently used item for
16 matches
Mail list logo
