And they're not random-access capable.
which means it isn't applicable?
Important point about WAH and friends is their ability to be fast
and/or/not/xor'ed without full decompression. And they're not
random-access capable.
On Fri, Nov 5, 2010 at 18:47, Uwe Schindler<u...@thetaphi.de> wrote:
Looks interesting, I was only annoyed when I saw "new Vector<Integer>()",
which is synchronized, in the iterator code - which is the thing that is
most important for DocIdSets.... Looks like stone ages.
Else I would simply give it a try by rewriting the class to also implement
DocIdSet and return the optimized iterator (not the one in this class). You
can then try to replace some OpenBitSets in any filters and perf test?
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-----Original Message-----
From: Peter Karich [mailto:peat...@yahoo.de]
Sent: Friday, November 05, 2010 3:38 PM
To: dev@lucene.apache.org
Subject: fast bitset
Hi,
would this compressed and fast(?) bitset be interesting for solr/lucene or
is
openbitset already done this way?
quoting from github:
The goal of word-aligned compression is not to achieve the best
compression,
but rather to improve query processing time.
License is GPL version 3 and ASL2.0.
http://code.google.com/p/javaewah
https://github.com/lemire/javaewah
I just saw it on twitter ...
Regards,
Peter.
--
http://jetwick.com twitter search prototype
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org