lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter
Date Sat, 09 Feb 2008 09:32:02 GMT
Op Saturday 09 February 2008 02:00:02 schreef robert engels:
> 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 see a LOT of code in Lucene that is very obtuse - mainly to gain  
> VERY small performance benefits.
> Isn't there a compelling case to not worry about this stuff, and let  
> the JVM people figure it out, and concentrate on writing clear, easy  
> to understand code.

Well, what is a good way to allow the JVM people to figure it out?

Once they have figured it out, we can remove those little

But the trick is not to think in we and they. There is quite a bit of
Apache licenced code in JVM's already.

> I think we are better off looking for data structure or algorithm  
> changes - these micro-improvements just lead to code bloat, and  
> maintenance headaches. I also think it is doubtful that future JVM  
> generations won't do them automatically anyway, any hand optimizing  
> might actually reduce performance.

I don't like the bloat either, but I'll gladly admit to having copied
some code, adapted it a bit, and proposed to have that adapted
copy added back into the code base. I wish there was a better way.

Paul Elschot

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message