and just one more for arguments sake, in Lucene "obscure bit twiddling" is "the great deal", have a look at all recent / old work on inverted index design, p4delta, rank9/16 ... it is nothing more nor less than "obscure bit twiddling"
----- Original Message ---- > From: eks dev <[EMAIL PROTECTED]> > To: java-dev@lucene.apache.org > Sent: Wednesday, 23 July, 2008 10:34:38 PM > Subject: Re: performance optimizations > > sure, nice article, big Ohhh notation should be addressed first, but > > try running Analyzers before Mike added char[] and compare > try Indexing with some older versions, basically nothing significantly > changed > from the algorithmic point of view Doug set years ago, all that happened > there > is just reducing constant factors, See work on Scorers and Filters where > Yonik > and Paul made some NICE gains on constant factors, nothing in O(N) is > better... > > I am on your side and I prefer, when I can choose, to have nice algorithmic > enhancements (e.g, one would be nice for SpellChecker that you cannot fix wit > constant factors, some smart Edit Distance without traversing all terms, O(N) > can e reduced and algos exist), but experience tells me that constant factor > can > hurt your performance equally bad as bad choice of algorithms... > > Work on flexibility and const. factor optimization is expected at this phase > of > lucene life cycle, Lucene is mature. > imo, no need to worry, lucene commiters proved many times that they are not > jumping too fast on accepting untested/unproved claims "great speed up by > doing > this or that"... standard answer is, "do you have valid test to prove it?" > > Both are important, performance is important for Lucene, at lest for me, it > is > money at the end, 10% faster means at lest 10% less hardware, 10% more user > experience... > > > > > > > > ----- Original Message ---- > > From: robert engels > > To: java-dev@lucene.apache.org > > Sent: Wednesday, 23 July, 2008 10:01:54 PM > > Subject: performance optimizations > > > > I hope this doesn't offend anyone, but I think this is an excellent > > article that the Lucene development team might find helpful. > > > > I have often been dismayed at complex code being written to achieve > > "negligible" performance improvements. Most often, a micro benchmark > > is used to justify the change. > > > > Worse, spending effort putting hacks into Lucene when they are > > clearly JVM bugs. I think it would be a far better use of resources > > to lobby Sun/others through the appropriate channels to get the > > underlying issue corrected. > > > > I know that there have been many performance improvements in Lucene > > as of late, but almost all of these have been algorithm changes - not > > obscure bit twiddling... > > > > Anyway, it is at http://java.sun.com/developer/technicalArticles/ > > Interviews/community/pepperdine_qa.html > > > > Robert > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > __________________________________________________________ > Not happy with your email address?. > Get the one you really want - millions of new email addresses available now > at > Yahoo! http://uk.docs.yahoo.com/ymail/new.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
