Mailing List Archive

On May 16, 2005, at 10:41 PM, Otis Gospodnetic wrote:
> Some interesting stuff...
>
> http://www.zedshaw.com/projects/ruby_odeum/performance.html

That's nice flamebait for sure. The fact of the matter is that JVM
startup speed is a well-known issue and to truly compare indexing/
searching speed the startup of the Ruby interpreter or JVM should not
be included.

Practically though, if your searches are occurring from command-line
tools then certainly the startup of the VM is a factor to consider,
sure. But in the Java world, most uses of Lucene would not be from a
command-line tool in this manner.

All that said - Odeum and the Ruby wrapper to it appear to be well
done and deserve great credit.

I am working on phasing more of my work into Ruby, so full-text
search in that environment is important to me (even if it means
having Java Lucene server communicating to Ruby).

The Ruby (and Rails) hype is a bit too antagonistic towards Java, and
the same is true in reverse with a lot of Java folks defensive
against Ruby. Ruby is a great language and I likely will be
developing more and more there.

Erik

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@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

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@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
>
>