Sorry if you thought my comment was destructive or counter-productive. I read all of Zed's posts on the subject and I feel he certainly presents a strong anti-Java, if not anti-Lucene bias - maybe just pro Ruby. The funny thing is that I am not a Java zealot by any means, and I am a firm believer in the "right tool for the job", but Zed's analysis is similar to testing screwdrivers, and then determining that one hammers nails way better than another.
If you do not even adhere to the principle designer's "guidelines to proper usage", your tests are meaningless. It's akin to using a new flat screen monitor and claiming "boy, it has a fuzzy picture", because you didn't follow the instructions that said "remove protective film before using". I just get frustrated when people use their "advanced methods" to prove their point (even though the statistics are very basic), but avoid the use of common sense. The adage "garbage in, garbage out" will always hold true. Zed is using a very constrained test - which is probably very UNCOMMON in the real world of server based systems, to attempt to discern the relative performance characteristics of Lucene/Java/Ruby/etc. The tests may be applicable in his poorly designed environment, but he presents his limited finding as "gospel", and that it should hold true in all cases. I quote... "For the people who have no clue (also known as "Executives") here's the information you need to tell all your employees they need to adopt the latest and greatest thing without ever having to understand anything you read. Cheaper than an article in CIO magazine and even has big words like "standard deviation"." and then goes on to present his "statistically correct" performance numbers. As an aside, in my performance testing of Lucene using JProfiler, it seems to me that the only way to improve Lucene's performance greatly can come from 2 areas 1. optimizing the JVM array/looping/JIT constructs/capabilities to avoid bounds checking/improve performance 2. improve function call overhead Other than that, other changes will require a significant change in the code structure (manually unrolling loops), at the sacrifice of readability/maintainability. R -----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 8:46 PM To: java-dev@lucene.apache.org Subject: Re: Lucene vs. Ruby/Odeum Robert - Please tone it down. Zed is aware of this thread and perhaps even seeing this message. There is no need to resort to such verbiage - Zed and I have been communicating and he is a fan of Lucene and has proven in his last entry that Lucene is faster than Ruby/Odeum even with the massive memory issue he notes (and has been properly informed of what he's doing incorrectly in that situation). Speaking for myself - I want the most accurate, flexible, and fastest search system possible regardless of platform or language. Certainly I want it to be Lucene, but I welcome competition and those that go to the extensive effort of collecting data and making studies such as Zed has. The Lucene community can help keep this type of competition healthy and positive by educating folks in proper Lucene usage and responding in kind regardless of the mistakes, attitudes, or flame- bait we may encounter. Erik On Jun 1, 2005, at 7:48 PM, Robert Engels wrote: > I think I am going to start a new Blog - "Zed's an Idiot". > > -----Original Message----- > From: Erik Hatcher [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 01, 2005 6:39 PM > To: java-dev@lucene.apache.org > Subject: Re: Lucene vs. Ruby/Odeum > > > > On Jun 1, 2005, at 6:07 PM, Daniel Naber wrote: > > >> On Tuesday 17 May 2005 04:41, Otis Gospodnetic wrote: >> >> >> >>> http://www.zedshaw.com/projects/ruby_odeum/performance.html >>> >>> >> >> Here's a follow up: >> http://www.zedshaw.com/projects/ruby_odeum/odeum_lucene_part2.html >> >> Now the claim is that Lucene is faster than Ruby/Odeum but it >> takes 36 >> times more memory. However, I cannot find any information on how >> exactly >> Lucene was started. It's no surprise that Java requires much memory >> and >> doesn't clean up if it never comes close to the limit set with -Xmx. >> > > I went around several times in e-mail with Zed, the author of this > comparison after his follow-up. His paraphrasing of me in there is > only partially sort of what I said to him. He's instantiating an > IndexSearcher inside a tight loop which I told him was a very bad > thing to do with Lucene and that his loops are so tight that garbage > collection isn't getting a chance to kick in. He doesn't currently > believe some of this from me, and also feels that adjusting the code > to make Lucene happy is being unfair. > > I wish the RubyLucene folks would hurry up and get a port over there > so that we could compare against Ruby/Odeum "fairly" :) > > Erik > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- 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]
