[
https://issues.apache.org/jira/browse/LUCENE-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913734#action_12913734
]
Ryan McKinley commented on LUCENE-2649:
---------------------------------------
bq. more performant too (and avoid more synchronizing lookups)
This was my motivation for putting it all together and using the options as
part of the key. But yes, inconsistent usage will eat up RAM. That is better
then my original fear that inconsistent usage would give you unpredictable
results!
Also, with the current Cache implementaion, we would need to somehow be able to
add two cache entries from within Cache.createEntry() -- either rewrite all
that or hack in some way to pass the FieldCache to the createEntry method.
Keeping the values and bits in different cache entries is pretty ugly
(especially for the normal case where we want them both all the time)
{code:java}
return new ByteValues() {
(byte[])caches.get(Byte.TYPE).get(reader, new Entry(field, parser??)),
(Bits)caches.get(Byte.TYPE).get(reader, new Entry(field, parser??)),
};
{code}
bq. But we could probably still achieve these two benefits while using a single
class for looking up everything "cached" about a field? Ie, the CachedArray
could return non-null bits but null values?
Brainstorming here... if Parser -> EnteryCreator and the
'EntryCreator.hashCode()' is used as the map key (as it is now)
{code:java}
public abstract class EntryCreator implements Serializable {
public boolean cacheValidBits() {
return false;
}
public boolean cacheValues() {
return true;
}
}
{code}
The trick would be to use the same *key* regardless of what we ask for (values
but no bits - bits but no values - bits and values, etc) and then fill up
whatever is missing if it is not in the existing cache.
That might suggest that the 'class' could be the key, but setting the
cacheValidBits/values would need to get implemented by inheratance, so that is
out.
other ideas? directions I am not thinking about?
> FieldCache should include a BitSet for matching docs
> ----------------------------------------------------
>
> Key: LUCENE-2649
> URL: https://issues.apache.org/jira/browse/LUCENE-2649
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Ryan McKinley
> Fix For: 4.0
>
> Attachments: LUCENE-2649-FieldCacheWithBitSet.patch,
> LUCENE-2649-FieldCacheWithBitSet.patch,
> LUCENE-2649-FieldCacheWithBitSet.patch,
> LUCENE-2649-FieldCacheWithBitSet.patch, LUCENE-2649-FieldCacheWithBitSet.patch
>
>
> The FieldCache returns an array representing the values for each doc.
> However there is no way to know if the doc actually has a value.
> This should be changed to return an object representing the values *and* a
> BitSet for all valid docs.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
