I would suggest that the Javolution folks do their tests against
modern JVM...
I have followed the Javolution project for some time, and while I
agree that some of the techniques should improve things, I think that
modern JVMs do most of this work for you (and the latest class
libraries also help - StringBuilder and others).
I also think that when you start doing you own memory management you
might as well write the code in C/C++ because you need to use similar
techniques (similar to the resource management when using SWT).
Just my thoughts.
On Apr 4, 2007, at 8:54 PM, Jean-Philippe Robichaud wrote:
Hello Dear Lucene coders!
Some of you may remember, I'm using lucene for a product (and many
other
internal utilities). I'm also using another open source library
called
Javolution (www.javolution.org <http://www.javolution.org/> ) which
does
many things, one of them being to offer excellent replacements for
ArrayList/Map/... and a super good memory management extension to the
java language.
As I'm [trying to] follow the conversations on this list, I see that
many of you are working towards optimizing lucene in term of memory
footprint and speed. I just finished optimizing my code (not lucene
itself, but my code written on top of it) using Javolution PoolContext
and the FastList/FastMap/... classes. The resulting speedup is a 6
times faster code.
Javolution make it easy to recycle objects and do some object
allocation
on the stack rather than on the head, which remove stress on the
garbage
collector. Javolution also offers 2 classes (Text and
TextBuilder) to
replace String/StringBuffer which are perfect for anything related to
string manipulation and some C "union/struct" equivalent for java.
The
thing is really great.
Would anyone be interested in doing Lucene a face lift and start using
javolution as a core lucene dependency? I understand that right now,
lucene is free of any dependencies, which is quite great, but anyone
interested in doing fast/lean/stable java application should seriously
consider using javolution anyway.
Any thoughts?
Jp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
