incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Host overriding of all non-final methods
Date Mon, 07 Mar 2011 05:03:00 GMT
On Fri, Mar 04, 2011 at 11:27:59PM -0800, Nathan Kurz wrote:
> On Wed, Mar 2, 2011 at 10:30 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> > Arguably, we don't even need the "final" keyword.  We'd should benchmark to
> > confirm my recollection about the performance implications, but I'll bet we
> > could remove it with no immediate impact on Lucy.
> 
> I'd suggest this as the cleanest solution.  Intuitively, I'd think
> that the benefit of 'final' would be very small, such that if one
> really cares about performance one should inline the function call
> completely and not worry about saving a single dereference.

Sounds good -- I'll work up a patch.  We'll leave the "inline" keyword in
Clownfish, but drop the "final" keyword.

Looking forward, we'll need to think about how to design our classes and
interfaces so that time-critical functionality can been inlined whenever
possible.  Java JIT compilers have the option of inlining even non-final
method bodies by branching for each known implementation at the site of the
method invocation (while providing a fallback branch for lazy-loaded classes).
That's an advantage we'll never have.  However, those kind of tricks are
notoriously unpredictable, and the Lucene folks have experienced a lot of
frustration trying to optimize around such optimizations.  Maybe we'll have a
little more luck with our manual inlining.

Our object structs are opaque, which limits our options since the inlined
functions have to go in header files.   However, we've had success with making
raw mmap'd buffers available via InStream_Buf() and Instream_Advance_Buf() so
that the inlined encoders/decoders in the NumUtils module can be deployed.
Perhaps we'll find other such opportunities.
 
> If you choose to keep 'final', I think assert() is really the right
> tool here, too.  You don't want the production system to fail because
> a programmer is trying to override something non-overridable, but you
> need to warn the user somehow.  Unit tests and asserts are not a "belt
> and suspenders" sort of redundancy.  Rather it's more of "shirt and
> pants" thing.  Both have their place socially, and there are
> situations one, the other, or neither are needed.  But rarely do you
> find yourself required to have at least one, but are allowed to choose
> which one that is.   But it's your house/project, and you're welcome
> to set your own dress code, even if it is a bit pedantic to test the
> limits of "Shirt and Shoes Required" by not wearing any pants.  (long
> day)

I don't work from home as much as I used to. ;)

Asserts are fine, of course -- they're SOP for lots of developers.  I'm not
arguing to exclude them from the Lucy codebase, just explaining why I haven't
made them a habit.  Who knows, maybe I'll amend my ways with time.

Marvin Humphrey


Mime
View raw message