[ https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Busch updated LUCENE-584: --------------------------------- Attachment: lucene-584-take5-part2.patch lucene-584-take5-part1.patch OK here's a new version of the patch. It's based on the take4 patch with the following changes: - removed BitSetFilter - added getBitSet() method to DocIdBitSet - added Paul's Test20080111.patch - changed TestScorerPerf to use a DocIdBitSet - changed ChainedFilterTest, CachedFilterBuilder, TestRemoteSearchable to use QueryWrapperFilter instead of deprecated QueryFilter Comments: - As mentioned in my previous comment it's not possible to wrap a CachingWrapperFilter around a BitSetFilter and then retrieve the BitSet from the CachingWrapperFilter. That's the reason why I removed BitSetFilter and added the getBitSet() method to DocIdBitSet instead. So you can do something like this: {code:java} DocIdSet docIdSet = filter.getDocIdSet(); if (docIdSet instanceof DocIdBitSet) { BitSet bits = ((DocIdBitSet) docIdSet).getBitSet(); ... } {code} - I didn't include Paul's ContribQueries20080111.patch because it only changes some contrib filters to extend BitSetFilter instead of Filter. - I like Eks' suggestion of implementing the BooleanFilter in a way that it can use any DocIdSetIterator and optimize special cases, when DocIdSet is a DocIdBitSet, OpenBitSet, etc. We should do this with a different JIRA issue - this patch is already big enough. All core & contrib tests pass. I'd like to commit this in a couple of days if nobody objects. > 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äfer > Assignee: Michael Busch > Priority: Minor > Fix For: 2.4 > > Attachments: bench-diff.txt, bench-diff.txt, > ContribQueries20080111.patch, lucene-584-take2.patch, > lucene-584-take3-part1.patch, lucene-584-take3-part2.patch, > lucene-584-take4-part1.patch, lucene-584-take4-part2.patch, > lucene-584-take5-part1.patch, lucene-584-take5-part2.patch, lucene-584.patch, > Matcher-20070905-2default.patch, Matcher-20070905-3core.patch, > Matcher-20071122-1ground.patch, Some Matchers.zip, Test20080111.patch > > > {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. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]