robert engels wrote: > Curious... on things like this, is it really worth adding (and > maintaining) Lucene's own sort, just to achieve a 1.5 % performance > increase. It is almost doubtful that you can even measure an improvement > at that level, given all of the variables you can't control. >
I somewhat agree with Robert here. The DocumentsWriter is a quite complicated class which has already two quicksort implementations and this patch adds even a third one. Is it really so much more expensive to e. g. sort on an Object[] array and pass in a Comparator? Don't get me wrong, I think this is very sophisticated code and it's super fast as the performance test and also the user experiences with 2.3 proof. However, I think especially in the Open Source world one of our goals should be to write code that is easy to understand, so that it's easier for new people to get on board. To find a good balance and trade-off between simplicity, functionality and performance is not always easy. Of course, if a patch improves performance by say 15%, I wouldn't hesitate to commit it. But if it's just 1% but makes the code more complicated I'm not so sure if it's worth it. That being said, I wouldn't vote -1 against a patch like this one to prevent someone from committing it, but I don't think I would write/commit it myself. I'd just like to encourage everyone to also think about code simplicity and readability before writing and committing new code. -Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
