
whoschek at lbl
May 17, 2005, 4:59 PM
Post #4 of 4
(4051 views)
Permalink
|
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: java-dev-unsubscribe [at] lucene >> For additional commands, e-mail: java-dev-help [at] lucene >> >> >> > >
|