On Mon, Jan 28, 2013 at 5:41 PM, Manik Surtani msurt...@redhat.com wrote:
On 28 Jan 2013, at 15:22, Vladimir Blagojevic vblag...@redhat.com wrote:
On 13-01-28 7:31 AM, Manik Surtani wrote:
If you're ok with changing the core, you could add a getValue() method
to CacheEntryCreatedEvent,
Wow. That's impressive. I presume the numbers change quite drastically the
moment we have a cache store configured though?
On 28 Jan 2013, at 23:53, Sanne Grinovero sa...@infinispan.org wrote:
These are preliminary results of our stressor; looks quite promising
as I haven't yet looked into
The second I have no idea how to implement as we do not have
CacheEntryExpired event. True, spec is not rigorous that such an event
has to be fired immediately after an entry has expired but eventually
(which might be on access). Either way, I am all ears on suggestions how
to
No I'm not comparing with Lucene 3.6 now with this configuration. It
is well known that Lucene 4 is significantly faster than Lucene 3, so
that would be unfair.
What is interesting is that when comparing our implementations vs. the
Apache stock ones while using Lucene 3 we where very close, often
Thinking about Sanne's idea re: a clock service and not continuously relying on
System.cTM, I stumbled upon this:
https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very
The last section re: caching is interesting.
Having all code use a Clock.currentTimeMillis() and having an
On 01/29/2013 02:30 PM, Sanne Grinovero wrote:
@Manik yes I'm not using a CacheStore, I would presume the same. This
is why I've created the Lucene-specific CacheLoader, maybe I should
complete the job and make it a CacheStore.
Oh yeah, a Lucene CacheStore would be nice.
Tristan
Glad you started work on that :)
Any currentTimeMillis() even today will blow away your cache line and
probably trigger a context switch.
Having it as a service we will be able to experiment: the first thing
I'll do is replace it with a NOOPService and see how much it improves.
Ideally I'd like
Interesting; looking at the code a bit more, I don't think this offers any
improvements except in the case where expiry is set. Granted, this is a useful
thing to have at that point, but I'm not entirely sure whether it will affect
the majority of users.
Anyway, to measure any benefit, I'm
On 1/29/13 5:02 PM, Manik Surtani wrote:
Thinking about Sanne's idea re: a clock service and not continuously relying
on System.cTM, I stumbled upon this:
https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very
The last section re: caching is interesting.
Having all code use
On 29 Jan 2013, at 17:17, Bela Ban b...@redhat.com wrote:
On 1/29/13 5:25 PM, Sanne Grinovero wrote:
Glad you started work on that :)
Any currentTimeMillis() even today will blow away your cache line and
probably trigger a context switch.
I understand the context switch (in general,
In order to accommodate some critical bug fixes, $Subject.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 29 Jan 2013, at 14:08, Dan Berindei wrote:
Very nice, looking forward to the Lucene bench results.
I hope you'll run it with a distributed cache as well!
+1 :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
12 matches
Mail list logo
