lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject RE: HitCollector: Why is it abstract?
Date Wed, 20 Feb 2002 17:15:42 GMT
> From: Eric Fixler []
> 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:

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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message