Mailing List Archive: HitCollector: Why is it abstract?

HitCollector: Why is it abstract?

Feb 19, 2002, 3:55 PM

Post #1 of 3 (555 views)

Hi again. I actually hadn't meant to send this may e-mails just after
joining the list, but here goes...

I'm wondering if there's a design reason why HitCollector is an abstract
class, rather than an interface.

BG: I am working to make a HitCollector to make it easier for me to work
with LuceneIndexer and a Search Results encapsulation class I wrote that
deals with searches from other sources.

While subclassing my SearchResults class I (or really, jikes) noticed
that HitCollector is an abstract class, not an interface. I can still
do my LuceneSearchResults class, but I'll need to use a nested class
instead of implementing HitCollector. Since there's no code in
HitCollector I was wondering if there was some reason for designating
this abstract; performance, future plans, whatever.

thx
eric

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

RE: HitCollector: Why is it abstract? [ In reply to ]

DCutting at grandcentral

Feb 20, 2002, 10:15 AM

Post #2 of 3 (548 views)

Permalink

> 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>

Re: HitCollector: Why is it abstract? [ In reply to ]

fix at smete

Feb 20, 2002, 6:10 PM

Post #3 of 3 (544 views)

Permalink

Thanks for the reply. I was really surprised by that data, it's really
good to know.

best
eric

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