Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <16139848.1176143612479.JavaMail.jira@brutus>
Date: Mon, 9 Apr 2007 11:33:32 -0700 (PDT)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-584) Decouple Filter from BitSet
In-Reply-To: <27200586.1149076109798.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-584?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487594 ]=20

Yonik Seeley commented on LUCENE-584:
-------------------------------------

> When you rerun, you may want to use my alg - to compare the two approache=
s in one run.

This is more dangerous though.  GC from one method's garbage can penalize t=
he 2nd methods performance.
Also, hotspot effects are hard to account for (if method1 and method2 use c=
ommon methods, method2 will often execute faster than method one because mo=
re optimization has been done on those common methods).

The hotspot effect can be minimized by running the test multiple times in t=
he same JVM instance and discarding the first runs, but it's not so easy fo=
r GC.

> Decouple Filter from BitSet
> ---------------------------
>
>                 Key: LUCENE-584
>                 URL: https://issues.apache.org/jira/browse/LUCENE-584
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.0.1
>            Reporter: Peter Sch=C3=A4fer
>            Priority: Minor
>         Attachments: bench-diff.txt, bench-diff.txt, BitsMatcher.java, Fi=
lter-20060628.patch, HitCollector-20060628.patch, IndexSearcher-20060628.pa=
tch, MatchCollector.java, Matcher.java, Matcher20070226.patch, Scorer-20060=
628.patch, Searchable-20060628.patch, Searcher-20060628.patch, Some Matcher=
s.zip, SortedVIntList.java, TestSortedVIntList.java
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable=20
> {
>   public abstract AbstractBitSet bits(IndexReader reader) throws IOExcept=
ion;
> }
> public interface AbstractBitSet=20
> {
>   public boolean get(int index);
> }
> {code}
> It would be useful if the method =3DFilter.bits()=3D returned an abstract=
 interface, instead of =3Djava.util.BitSet=3D.
> Use case: there is a very large index, and, depending on the user's privi=
leges, only a small portion of the index is actually visible.
> Sparsely populated =3Djava.util.BitSet=3Ds are not efficient and waste lo=
ts of memory. It would be desirable to have an alternative BitSet implement=
ation with smaller memory footprint.
> Though it _is_ possibly to derive classes from =3Djava.util.BitSet=3D, it=
 was obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementat=
ion could still delegate to =3Djava.util.BitSet=3D.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org