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. > 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. ;) Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
