On Wed, Jan 13, 2010 at 9:12 PM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Wed, Jan 13, 2010 at 11:46:50AM -0500, Michael McCandless wrote: >> If forced to pick, in general, I tend to prefer burning CPU not RAM, >> because the CPU is often a one-time burn, whereas RAM ties up storage >> for indefinite amounts of time. > > With our dependence on indexes being RAM-resident for optimum performance, I'd > also favor being conservative with RAM.
OK let's tentatively stick with 1/8th asymptotic growth... >> I think this function should still aim to handle the smallish values, >> ie, we shouldn't require every caller to have to handle the small >> values themselves. Callers that want to override the small cases can >> still do so... > > The more "helpful" the behavior of getNextSize(), the harder it is to > understand what happens when you partially override it. > > But I guess it's not that big a deal one way or the other. There aren't that > many places in Lucene where you might call getNextSize(). There are more such > places in Lucy because we have to roll our own string and array classes, and > we need finer-grained control over what happens there -- so maybe that > explains why I'm not excited about trying to cram all that logic into a shared > routine. > > Putting more logic into getNextSize() would be less of a problem if Lucene's > implementation was less convoluted. It's only one line and one comment, but > it's deceptively difficult to grok. > Looks like some Perl golfer wrote it. ;) Yes! I'm laughing over here... I'll verbosify the comment and try to fold in some of the ideas from this thread.... I'll work up a patch. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
