On Fri, Mar 04, 2011 at 11:27:59PM -0800, Nathan Kurz wrote: > On Wed, Mar 2, 2011 at 10:30 PM, Marvin Humphrey <[email protected]> > 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
