[
https://issues.apache.org/jira/browse/LUCENE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830599#action_12830599
]
John Wang commented on LUCENE-2252:
-----------------------------------
Thanks Uwe for the pointer. Will check that out!
Robert, we can get away with 4 bytes per doc assuming we are not storing 2GB of
data per doc. This memory would be less than the data structure needed to be
held in memory for only 1 field cache entry for sort. I understand it is always
better to use less memory, but sometimes we do have to make trade-off decisions.
But you are right, different applications have different needs/requirements, so
having support for custom segments would be a good thing. e.g. LUCENE-1914
> stored field retrieve slow
> --------------------------
>
> Key: LUCENE-2252
> URL: https://issues.apache.org/jira/browse/LUCENE-2252
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 3.0
> Reporter: John Wang
>
> IndexReader.document() on a stored field is rather slow. Did a simple
> multi-threaded test and profiled it:
> 40+% time is spent in getting the offset from the index file
> 30+% time is spent in reading the count (e.g. number of fields to load)
> Although I ran it on my lap top where the disk isn't that great, but still
> seems to be much room in improvement, e.g. load field index file into memory
> (for a 5M doc index, the extra memory footprint is 20MB, peanuts comparing to
> other stuff being loaded)
> A related note, are there plans to have custom segments as part of flexible
> indexing feature?
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
