That represents a pretty significant performance regression though, and it seems we should try to avoid stuff like that on trunk (better in a branch if one is going to remove functionality with the idea of adding it back later).
Well we haven't released trunk yet, and this is not a perf regression
Ie, there's no guarantee w/in trunk that performance won't "change",
just like there's no guarantee APIs and index format won't "change".
Or we could generate the bits by default - the extra cache entry if not needed is less serious than doubling the generation time.
I'd rather not do that; apps that don't use sort missing first/last
shouldn't be forced to spend the RAM (even if it's only a bit per
I think we can find a solution that makes it optional; I just don't
think we have to do it here, now.
This issue can focus on getting to 3.x's FC impl.
Another small piece we are losing from trunk is numUniqueTerms.
Well, we track this in FC (only in trunk) today, but it's not used
anywhere, I think? Also, this is redundant with
What about returning an object, so instead of getLongs() returning a long, it would return a LongValues that had
a long as well as numUniqueTerms, and docsWithValues (optionally set). This also halves the number of cache lookups needed when using sortMissinglast and supplies a place to put more info in the future (stuff like numUniqueTerms).
I think for now we should stick w/ simple arrays for this issue; we
can explore returning an object under a new issue. The extra cache
lookup is really a negligible cost.