Right. One doesn't need to run those benchmarks to immediately see
that most time is spent in VM startup, class loading, hotspot
compilation rather than anything Lucene related. Even a simple
System.out.println("hello") typically takes some 0.3 secs on a fast
box and JVM.
Wolfgang.
On May 17, 2005, at 7:33 AM, Scott Ganyo wrote:
Interesting, but questionable. I can imagine three problems with
the write-up just off-hand:
1) JVM startup time. As the author noted, this can be an issue
with short-running Java applications.
2) JVM warm-up time. The HotSpot VM is designed to optimize itself
and become faster over time rather than being the fastest right out
of the blocks.
3) Data access patterns. It is possible (I don't know) that Odeum
is designed for quick one-time search on the data without reading
and caching the index like Lucene does for subsequent queries.
In each case, there is a common theme: Lucene and Java are
designed to perform better for longer-running applications... not
start, lookup, and terminate utilities.
S
On May 16, 2005, at 9:41 PM, Otis Gospodnetic wrote:
Some interesting stuff...
http://www.zedshaw.com/projects/ruby_odeum/performance.html
http://blog.innerewut.de/articles/2005/05/16/ruby-odeum-vs-apache-
lucene
---------------------------------------------------------------------
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]
