Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter

2008-02-10 Thread Mike Klaas
Certainly others do agree with you to some degree that this case is on the cost/benefit borderline. Again, this case wasn't really the point. My point was it feels to me that you have, on occasion, been over- quick to criticize without paying sufficiently respectful attention to the detai

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

2008-02-10 Thread Doron Cohen (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567525#action_12567525 ] Doron Cohen commented on LUCENE-1157: - So there will be: http://svn.apache.org/rep

Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter

2008-02-10 Thread robert engels
Please chill. You are inferring something that was not implied. You may think it lacks perspective and respect (I disagree on both), but it certainly doesn't lack in correctness. First, depending on how you measure it, 2x speedup equates to a 50% reduction in time. In my review of the chang

Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter

2008-02-10 Thread Mike Klaas
While I agree in general that excessive optimization at the expense of code clarity is undesirable, you are overstating the point. 2X is a ridiculous threshold to apply to something as performance critical as a full text search engine. If search was twice as slow, lucene would be utterly

Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter

2008-02-10 Thread robert engels
As a followup, I think when people report timing numbers they should be done on a *nix, so that you can report, real, user, system and wait for io times. Even with this, there are other issues (JVM compilation times, GC times), etc. that will affect the relevancy of the timings. On Feb 1

Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter

2008-02-10 Thread robert engels
I am not sure these numbers matter. I think they are skewed because you are probably running too short a test, and the index is in memory (or OS cache). Once you use a real index that needs to read/write from the disk, the percentage change will be negligible. This is the problem with man

Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter

2008-02-10 Thread Michael McCandless
Yonik Seeley wrote: I wonder how well a single generic quickSort(Object[] arr, int low, int high) would perform vs the type-specific ones? I guess the main overhead would be a cast from Object to the specific class to do the compare? Too bad Java doesn't have true generics/templates. OK I

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

2008-02-10 Thread Steven Rowe (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567458#action_12567458 ] Steven Rowe commented on LUCENE-1157: - I think the simplest thing to do would be to pu

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

2008-02-10 Thread Doron Cohen (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567416#action_12567416 ] Doron Cohen commented on LUCENE-1157: - Yes, I was kinda not sure what to do next - clo