Yonik,
any reason to have BitSetItrator method
int next(int fromIndex) {...
package protected
Would be interesing to see how BitSetIterator works in Matcher, skipping is
needed there
----- Original Message ----
From: paul.elschot (JIRA) <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Monday, 4 September, 2006 8:47:24 AM
Subject: [jira] Commented: (LUCENE-584) Decouple Filter from BitSet
[
http://issues.apache.org/jira/browse/LUCENE-584?page=comments#action_12432435 ]
paul.elschot commented on LUCENE-584:
-------------------------------------
> No performance changes as well.
It's good to hear that. As mentioned earlier, this is groundwork only.
Once an actual Matcher is used I expect some some performance differences to
show up.
Which comment of Yonik related to HitCollector do you mean?
> Early this week we will try to implement our first Matchers and see how they
> behave
BitsMatcher and SortedVIntList could start that.
Also I'd like to see one on Solr's OpenBitSet...
> Decouple Filter from BitSet
> ---------------------------
>
> Key: LUCENE-584
> URL: http://issues.apache.org/jira/browse/LUCENE-584
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.0.1
> Reporter: Peter Schäfer
> Priority: Minor
> Attachments: BitsMatcher.java, Filter-20060628.patch,
> HitCollector-20060628.patch, IndexSearcher-20060628.patch,
> MatchCollector.java, Matcher.java, Matcher20060830b.patch,
> Scorer-20060628.patch, Searchable-20060628.patch, Searcher-20060628.patch,
> SortedVIntList.java, TestSortedVIntList.java
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable
> {
> public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet
> {
> public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract
> interface, instead of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's
> privileges, only a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
> memory. It would be desirable to have an alternative BitSet implementation
> with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
> obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementation
> could still delegate to =java.util.BitSet=.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
