[
https://issues.apache.org/jira/browse/LUCENE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649637#action_12649637
]
Paul Elschot commented on LUCENE-1461:
--------------------------------------
{quote}I tried a short[] array and it is about 20% faster than the int[] array
(I'm assuming this is a memory bandwidth issue.) {quote}
20% is more than I expected. Have a look at LUCENE-1410 for optimal bit packing
in a frame of reference. There are also some performance numbers there for
different numbers of frame bits. (A short[] is equivalent to 16 frame bits.)
This 20% means that it could well be wortwhile to always use such a frame for
the docContents here.
I would not expect that TermMultiFilter has an advantage over a TermFilter,
since it does a linear search even for skipTo(). The only advantage it has it
that it does the linear search from memory where TermFilter does its skipping
using the skip info in the index.
Would anyone else have an idea where this could be added, in core or contrib,
and what (new) package name could be used?
> Cached filter for a single term field
> -------------------------------------
>
> Key: LUCENE-1461
> URL: https://issues.apache.org/jira/browse/LUCENE-1461
> Project: Lucene - Java
> Issue Type: New Feature
> Reporter: Tim Sturge
> Attachments: DisjointMultiFilter.java, RangeMultiFilter.java,
> TermMultiFilter.java
>
>
> These classes implement inexpensive range filtering over a field containing a
> single term. They do this by building an integer array of term numbers
> (storing the term->number mapping in a TreeMap) and then implementing a fast
> integer comparison based DocSetIdIterator.
> This code is currently being used to do age range filtering, but could also
> be used to do other date filtering or in any application where there need to
> be multiple filters based on the same single term field. I have an untested
> implementation of single term filtering and have considered but not yet
> implemented term set filtering (useful for location based searches) as well.
> The code here is fairly rough; it works but lacks javadocs and toString() and
> hashCode() methods etc. I'm posting it here to discover if there is other
> interest in this feature; I don't mind fixing it up but would hate to go to
> the effort if it's not going to make it into Lucene.
--
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]
