On 11-11-02 11:39 AM, Sanne Grinovero wrote:
I've experimented with some implementations; since the simplest
approach just removes and simplifies code while providing a
significant speedup I'm going to send a pull request for that one: I
just have to add some additional methods to
On 3 November 2011 15:47, Vladimir Blagojevic vblag...@redhat.com wrote:
Sanne have you integrated this? I would love to see what you have done!
Yes it's in master as ISPN-1459
Again it's a super-simple patch; it's all about
the following change:
for each entry {
long now =
On 30 Oct 2011, at 23:58, Dan Berindei wrote:
Cool link Elias, I read the paper linked in the javadoc and it's very
interesting.
Netty seems to use scheme 6 (a single array of lists with hashing and
without any overflow). I believe in general our timeouts will be much
longer so I suspect
I've experimented with some implementations; since the simplest
approach just removes and simplifies code while providing a
significant speedup I'm going to send a pull request for that one: I
just have to add some additional methods to InternalCacheEntry, and
get a good improvement in the
Cool link Elias, I read the paper linked in the javadoc and it's very
interesting.
Netty seems to use scheme 6 (a single array of lists with hashing and
without any overflow). I believe in general our timeouts will be much
longer so I suspect scheme 5 or scheme 7 should perform better for us.
On 20 Oct 2011, at 08:47, Galder Zamarreño wrote:
Why are we preferring to provide more cache misses slower
performance, to fake a slightly better precision in eviction?
I guess this is the main question, how much worse would the eviction
precision be if we only relied on the periodic
On 27 October 2011 16:58, Manik Surtani ma...@jboss.org wrote:
On 20 Oct 2011, at 08:47, Galder Zamarreño wrote:
Why are we preferring to provide more cache misses slower
performance, to fake a slightly better precision in eviction?
I guess this is the main question, how much worse would
Rather than a heap, I recall Netty had a hash wheel timer[1]. Which should
be better performing than a heap. You could get clever by having
multiple heaps, segmented by orders of magnitude. For example wheel 1
could have 1 minute, 2 1 hour etc. Netty uses a lot of short lived
timers and performs
On Oct 19, 2011, at 2:13 PM, Dan Berindei wrote:
On Tue, Oct 18, 2011 at 10:57 AM, Sanne Grinovero sa...@infinispan.org
wrote:
The replies so far are very interesting, but at this stage I'd be more
interested in discussing the fundamental question:
Why are we preferring to provide more
On Tue, Oct 18, 2011 at 10:57 AM, Sanne Grinovero sa...@infinispan.org wrote:
The replies so far are very interesting, but at this stage I'd be more
interested in discussing the fundamental question:
Why are we preferring to provide more cache misses slower
performance, to fake a slightly
On Tue, Oct 18, 2011 at 1:32 AM, Mircea Markus mircea.mar...@jboss.com wrote:
On 17 Oct 2011, at 14:13, Sanne Grinovero wrote:
Very interesting, I knew that in Windows currentTimeMillis() basically
just reads a volatile because I got bit by the 15 millisecond accuracy
issue before, so I
The replies so far are very interesting, but at this stage I'd be more
interested in discussing the fundamental question:
Why are we preferring to provide more cache misses slower
performance, to fake a slightly better precision in eviction?
Since we can't guarantee precision, I'd want to
On 17 October 2011 09:02, Dan Berindei dan.berin...@gmail.com wrote:
On Sat, Oct 15, 2011 at 7:25 PM, Sanne Grinovero sa...@infinispan.org wrote:
Hi all,
I'm looking at some performance details, and noticed the current code
is using System.currentTimeMillis() to estimate performance for short
On 17 Oct 2011, at 14:13, Sanne Grinovero wrote:
Very interesting, I knew that in Windows currentTimeMillis() basically
just reads a volatile because I got bit by the 15 millisecond accuracy
issue before, so I thought it would always be very fast. I had no idea
on Linux it would have the
Hi all,
I'm looking at some performance details, and noticed the current code
is using System.currentTimeMillis() to estimate performance for short
lived operations.
For the purpose of CacheMgmtInterceptor we should use System.nanoTime() instead:
15 matches
Mail list logo
