Hi Marc, in theory we apply all the same optimisations as the "Lucene edition", including the "acceptDocs" Bits as described in LUCENE-1536.
These are the main differences of our implementation: - uses the SoftLimitMRUCache rather than a synchronized WeakHashMap - uses Soft rather than Weak references - we do prevent duplicate computation for the same segments in case of race conditions to prevent unnecessary CPU usage Overall I'd expect this to perform better than the Lucene vanilla version; that's probably not something I could state as an universal truth but it's reasonable for our kind of integration. For example, making those keys "weak" rather than "soft" would keep all filter instances in memory, without any kind of upper bound: yes that might look like "faster" in a couple of small tests but it's probably not what you want! Am I wrong? Please let me know if you've been measuring this and got to different conclusions. The drawback of soft keys is of course that in case you need a full gc for other reasons, your cache is cleared. If that's your problem, we should discuss about more advanced cache tuning options. Sanne On 15 February 2015 at 20:05, Marc Schipperheyn <m.schipperh...@gmail.com> wrote: > Just wondering with Lucene 4 whether the Hibernate CachingWrapperFilter > should leverage that instead of using its own caching implementation. Given > the discussion in LUCENE-1536. > > I'm not superfamiliar with this part of the code, but it looks like the > LUCENE-1536 allows optimization at a deeper level. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
