lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <DCutt...@grandcentral.com>
Subject RE: HitCollector: Why is it abstract?
Date Wed, 20 Feb 2002 17:15:42 GMT
> From: Eric Fixler [mailto:fix@smete.org]
> 
> I'm wondering if there's a design reason why HitCollector is 
> an abstract class, rather than an interface.

I don't recall my thinking, if any, when I did this.

An interface is more flexible, since it can be a mix-in, but calls to
interfaces are slower on some JVMs.  HitCollector does need to be efficient,
so this could be be significant.

I just searched around and found a benchmark at:
  http://waitaki.otago.ac.nz/~bryce/gcj/meth-inv-bench.tar.gz

With IBM's 1.3 Linux JVM I get:
  no call:           90ms [9ns / call]
  local:             30ms [3ns / call]
  private:           30ms [3ns / call]
  interface:        381ms [38ns / call]
  i/f after cast:   301ms [30ns / call]
  abstract:          30ms [3ns / call]
  abstract w/cast:   46ms [4ns / call]

With Sun's 1.3 or 1.4 on Win2k I get:
  no call:           100ms [10ns / call]
  local:             331ms [33ns / call]
  private:            90ms [9ns / call]
  interface:         341ms [34ns / call]
  i/f after cast:    330ms [33ns / call]
  abstract:          331ms [33ns / call]
  abstract w/cast:   300ms [30ns / call]

So for at least some JVMs interfaces are still slower to call than abstract
methods.  Whether this is enough to make a measurable difference with
HitCollector is an experiment I'd like to see conducted before changing
HitCollector to be an interface.

Doug

--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message