>
> It also seems that many more "obscure, index corruption" type bugs
> have crept in as the pursuit of performance has taken place, whereas
> the 1.9 and prior code was very stable.
come on, this bug you point to is clear jvm bug that Lucene community
contributed back to Sun... on the other side, "if you make no changes you make
no bugs" does not really work
>
> If you could gain 10% performance, by making the code 50% more
> complex, to run on a 1.5 JVM, when the existing code works 30% faster
> on a 1.6 JVM (on the same hardware), do you do it?
Sure, you could equally argue like, "why bother now, eventually Quantum CPUs
will become standard"... loosing something today to gain something else today
is imo totally acceptable, as long as you have responibility and experiance to
make jugment abot right balance... you know, it is kind of phlosophicall, do
you remeber this bird in "Catch 22" "Hier and now! Hier and now!"
this is kind of discussion that is well suitable for quiet afternoon over the
weekend among students in campus, I miss it sometimes but I cannot afford it
anymore, too old for it :)
Let us move from abstract to concrete, do you have concrete case where you
beleive an issue X is being misjudged in that sense (complexity vs performance
beneffit)? Show us algorithmic alternatives, give us a patch, test, articles,
ideas...
as one of my proffesors at the university said, after hevy schedule over
relatinal agebra formalisms ..."...but... at the end of day, all that conts is
the code that executes"
cheers,
eks
__________________________________________________________
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]
