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.
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.
On Feb 8, 2008, at 6:52 PM, Michael McCandless (JIRA) wrote:
Small speedups to DocumentsWriter
---------------------------------
Key: LUCENE-1172
URL: https://issues.apache.org/jira/browse/
LUCENE-1172
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Affects Versions: 2.3
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor
Fix For: 2.4
Attachments: LUCENE-1172.patch
Some small fixes that I found while profiling indexing Wikipedia,
mainly using our own quickSort instead of Arrays.sort.
Testing first 200K docs of Wikipedia shows a speedup from 274.6
seconds to 270.2 seconds.
I'll commit in a day or two.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
