hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliott Clark <ecl...@stumbleupon.com>
Subject Re: deprecating (old) metrics in favor of metrics2 framework
Date Thu, 12 Jul 2012 02:07:02 GMT
Yep.  This is pretty darn close to DI.  I would be willing to change the
patch that I just put up to use Guice if that's what people wanted.  I know
some of our classes could use some DI loving to help with testability.

On Wed, Jul 11, 2012 at 11:57 AM, Andrew Purtell <apurtell@apache.org>wrote:

> On Wed, Jul 11, 2012 at 10:50 AM, Elliott Clark <eclark@stumbleupon.com>
> wrote:
> [...]
> >
> > The reflection option seems like it would be a big perf hit.  Reflection
> > basically means that nothing ever gets inlined so all function calls into
> > metrics2 code would be very expensive.  Since it seems like we are adding
> > more and more instrumentation this perf impact would only grow.
> >  In addition as more hadoop versions come out all of our reflection code
> > would get much more complicated and brittle.
> >
> > The conditionally loaded jar would be nice in that the JIT would only see
> > one version of the factory classes on the classpath and everything could
> be
> > optimized just like any other jvm run jit'd code. In addition there are
> > other places that we use reflection to do things conditionally and a
> > conditionally loaded jar would be nice.
> Coprocessors are a solution close to conditionally loaded JARs: there
> is not reflection, very frequently executed code would be JITed, the
> only thing missing is direct inlining.
> More and more (useful) metrics are going into hot paths, we want all
> three I think.
> We keep inching toward DI.
> Best regards,
>    - Andy
> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein (via Tom White)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message