: I wouldn't expect there to be much of a difference. Lazy fields hold
: on to a stream and an offset, and operate by seek()'ing to the right
...
Hmmm... yeah it sounds like it shouldn't matter. If i get soem time i'll
try to do a micro benchmark to compare loading a doc with one field and
then loading the rest lazy vs loading the doc twice.
: > An alternate idea: the single arg version could check if an item found in
: > the cache contains lazy fields and if so re-fetch and recache the full
: > Document?
:
: That could work though I wonder if the O(num fields) cost per document
: access is worth it. Perhaps the document could be stored with a
: "lazy" flag in the cache, to make this check O(1).
right ... checking the individual fields would be a very bad idea.
: Perhaps instead of a "lazy" flag, the number of real fields could be
: stored in the cache. On the next document request, if there are more
: than 1-2 more fields requeste than "real" in the cache, the full
: document is returned.
that's the kind of crazy, hueristic/AIish kind of soulution approach I
love! ... but probably not worth the effort unless we see a demonstratable
problem.
: How much of a problem this is depends also on how often documets are
: hit once in the cache. If it if more than a few times, the load-once
: behaviour of lazy fields should amortize out the extra cost.
right ... and if it's not more then a few times, you might as well skip
the doc cache completely.
: > 2) why doesn't optimizePreFetchDocs use SolrIndexSearcher.readDocs (looks
: > like cut/paste of method body)
:
: Avoids the allocation of the Document[] array, and is three lines (vs.
: two lines to allocate array and call readDocs).
Ah ... that makes sense.
-Hoss
