commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [proxy] and impl
Date Thu, 01 Aug 2013 15:59:29 GMT
This is rudimentary off the top of my head, but the following code
produces this output:

It took a total of 9.022382 seconds using $Proxy0.
It took a total of 5.528322 seconds using
TestAnnotationTrainer$Foo$$EnhancerByCGLIB$$c462c19e.
It took a total of 5.084160 seconds using JavassistUtilsGenerated_1.

I'm sure it's not the most scientific, but it's a start.

private static void benchmark(Foo[] foos, long n)
    {
        final long totals[] = new long[foos.length];
        for (int count = 0; count < n; ++count)
        {
            for (int i = 0; i < foos.length; i++)
            {
                Foo foo = foos[i];
                final long before = System.nanoTime();
                for (int j = 0; j < 10000; ++j)
                {
                    foo.bar();
                }
                totals[i] += System.nanoTime() - before;
            }
        }
        for (int i = 0; i < foos.length; i++)
        {
            Foo foo = foos[i];
            System.out.println(String.format("It took a total of %f
seconds using %s.", totals[i] / 1000000000.0,
foo.getClass().getSimpleName()));
        }
    }

//----------------------------------------------------------------------------------------------------------------------
// Inner Classes
//----------------------------------------------------------------------------------------------------------------------

    public static interface Foo
    {
        public void bar();
    }

    public static class FooImpl implements Foo
    {
        @Override
        public void bar()
        {

        }
    }

//----------------------------------------------------------------------------------------------------------------------
// main() method
//----------------------------------------------------------------------------------------------------------------------

    public static void main(String[] args)
    {
        CglibProxyFactory cglib = new CglibProxyFactory();
        JdkProxyFactory jdk = new JdkProxyFactory();
        JavassistProxyFactory javassist = new JavassistProxyFactory();
        ObjectProvider<Foo> provider =
ObjectProviderUtils.<Foo>constant(new FooImpl());
        Foo cglibFoo = cglib.createDelegatorProxy(provider, Foo.class);
        Foo jdkFoo = jdk.createDelegatorProxy(provider, Foo.class);
        Foo javassistFoo = javassist.createDelegatorProxy(provider, Foo.class);

        final Foo[] foos = new Foo[]{jdkFoo, cglibFoo, javassistFoo};

        benchmark(foos, 100000);


    }
}

On Thu, Aug 1, 2013 at 11:15 AM, Romain Manni-Bucau
<rmannibucau@gmail.com> wrote:
> hehe, do you have figures?
>
> when JIT did its work reflection is almost free. You can update the asm
> proxy factory to handle 3 implementations but it is not worth it IMO
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/8/1 James Carman <james@carmanconsulting.com>
>
>> You're going to lose the benefit of having ASM if you just end up
>> using reflection to call the methods anyway aren't you?  The Javassist
>> code actually generates Java code that actually calls the real method
>> on an instance of the appropriate type.  That's what makes it faster.
>>
>> On Thu, Aug 1, 2013 at 10:57 AM, Romain Manni-Bucau
>> <rmannibucau@gmail.com> wrote:
>> > No, but believe me you want a handler (this one or invoker) to maintain
>> the
>> > code and keep it easy.
>> >
>> > *Romain Manni-Bucau*
>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> > *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> > *Github: https://github.com/rmannibucau*
>> >
>> >
>> >
>> > 2013/8/1 Matt Benson <gudnabrsam@gmail.com>
>> >
>> >> That's my point; it doesn't.
>> >>
>> >>
>> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
>> james@carmanconsulting.com
>> >> >wrote:
>> >>
>> >> > Does the ASM API require a java.lang.reflect.InvocationHandler?
>> >> >
>> >> > On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau
>> >> > <rmannibucau@gmail.com> wrote:
>> >> > > Well for the maintainance it is easier (and not really slower)
to
>> use a
>> >> > > little abstraction. InvocationHandler/Inoker is fine. Since JdkProxy
>> >> uses
>> >> > > the exact same code i throught it could be shared.
>> >> > >
>> >> > > *Romain Manni-Bucau*
>> >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >> > > *Blog: **http://rmannibucau.wordpress.com/*<
>> >> > http://rmannibucau.wordpress.com/>
>> >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >> > > *Github: https://github.com/rmannibucau*
>> >> > >
>> >> > >
>> >> > >
>> >> > > 2013/8/1 Matt Benson <gudnabrsam@gmail.com>
>> >> > >
>> >> > >> The behavior of proxies is specified by Invokers, ObjectProviders,
>> and
>> >> > >> Interceptors. Each ProxyFactory implementation bridges from
these
>> >> > >> interfaces to the most appropriate mechanism specific to the
target
>> >> > >> technology. In the case of ASM, I would think that would be
direct
>> >> calls
>> >> > >> against the proxy interface implementations themselves.
>> >> > >>
>> >> > >> Matt
>> >> > >> On Aug 1, 2013 9:21 AM, "Romain Manni-Bucau" <
>> rmannibucau@gmail.com>
>> >> > >> wrote:
>> >> > >>
>> >> > >>> a sed shold almost work but the issue is the same: the
code is
>> >> > >>> duplicated, no? is there invoker elsewhere?
>> >> > >>>
>> >> > >>> *Romain Manni-Bucau*
>> >> > >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >> > >>> *Blog: **http://rmannibucau.wordpress.com/*<
>> >> > http://rmannibucau.wordpress.com/>
>> >> > >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >> > >>> *Github: https://github.com/rmannibucau*
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> 2013/8/1 Matt Benson <gudnabrsam@gmail.com>
>> >> > >>>
>> >> > >>>> But is there some technical reason why it's helpful
for ASM
>> proxies
>> >> to
>> >> > >>>> use
>> >> > >>>> InvocationHandler specifically?  Why wouldn't they
just use
>> Invoker
>> >> > >>>> directly?
>> >> > >>>>
>> >> > >>>> Matt
>> >> > >>>>
>> >> > >>>>
>> >> > >>>> On Thu, Aug 1, 2013 at 8:51 AM, Romain Manni-Bucau
<
>> >> > >>>> rmannibucau@gmail.com>wrote:
>> >> > >>>>
>> >> > >>>> > +1
>> >> > >>>> >
>> >> > >>>> > jdkproxyfactory can even be hardcoded as a default
IMO (without
>> >> > using
>> >> > >>>> the
>> >> > >>>> > SPI)
>> >> > >>>> >
>> >> > >>>> >
>> >> > >>>> > *Romain Manni-Bucau*
>> >> > >>>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >> > >>>> > *Blog: **http://rmannibucau.wordpress.com/*<
>> >> > >>>> > http://rmannibucau.wordpress.com/>
>> >> > >>>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >> > >>>> > *Github: https://github.com/rmannibucau*
>> >> > >>>> >
>> >> > >>>> >
>> >> > >>>> >
>> >> > >>>> > 2013/8/1 James Carman <james@carmanconsulting.com>
>> >> > >>>> >
>> >> > >>>> > > You mean all the InvocationHandler classes
in JdkProxy?  I
>> guess
>> >> > we
>> >> > >>>> > > could break those out into top-level classes,
but then you'd
>> >> have
>> >> > >>>> > > multiple implementations on your classpath
if you made a
>> >> > dependency
>> >> > >>>> on
>> >> > >>>> > > commons-proxy-jdk.  We could move those
to "core" I guess.
>> >> > >>>> > >
>> >> > >>>> > > On Thu, Aug 1, 2013 at 7:49 AM, Romain Manni-Bucau
>> >> > >>>> > > <rmannibucau@gmail.com> wrote:
>> >> > >>>> > > > Ok for all excepted last point (i was
not clear i think).
>> The
>> >> > >>>> > > ProxyFactory
>> >> > >>>> > > > impl using jdk proxy uses Invocationhandler
like the asm
>> >> > >>>> implementation
>> >> > >>>> > > so
>> >> > >>>> > > > it would be great to be able to share
the handler classes
>> >> > between
>> >> > >>>> both
>> >> > >>>> > > impl.
>> >> > >>>> > > >
>> >> > >>>> > > > *Romain Manni-Bucau*
>> >> > >>>> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >> > >>>> > > > *Blog: **http://rmannibucau.wordpress.com/*<
>> >> > >>>> > > http://rmannibucau.wordpress.com/>
>> >> > >>>> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >> > >>>> > > > *Github: https://github.com/rmannibucau*
>> >> > >>>> > > >
>> >> > >>>> > > >
>> >> > >>>> > > >
>> >> > >>>> > > > 2013/8/1 James Carman <james@carmanconsulting.com>
>> >> > >>>> > > >
>> >> > >>>> > > >> On Thu, Aug 1, 2013 at 2:44 AM,
Romain Manni-Bucau
>> >> > >>>> > > >> <rmannibucau@gmail.com> wrote:
>> >> > >>>> > > >> > ok,
>> >> > >>>> > > >> >
>> >> > >>>> > > >> > here it is: https://gist.github.com/rmannibucau/6128964
>> >> > >>>> > > >> >
>> >> > >>>> > > >>
>> >> > >>>> > > >> Thanks!
>> >> > >>>> > > >>
>> >> > >>>> > > >> >
>> >> > >>>> > > >> > 1) i didn't fully get the
goal of stub module, any
>> >> pointers?
>> >> > >>>> > > >>
>> >> > >>>> > > >> It provides features very similar
to the mocking support
>> in
>> >> > >>>> libraries
>> >> > >>>> > > >> like Mockito/EasyMock.  Basically,
you can "train" a
>> proxy to
>> >> > do
>> >> > >>>> what
>> >> > >>>> > > >> you want in certain situations.
>> >> > >>>> > > >>
>> >> > >>>> > > >> > 2) in ProxyFactory methods
have this kind of signature
>> >> > >>>> > > >> >
>> >> > >>>> > > >> > <T> T createDelegatorProxy(
ClassLoader classLoader,
>> >> > >>>> > ObjectProvider<?>
>> >> > >>>> > > >> > delegateProvider,
>> >> > >>>> > > >> >                          
              Class<?>...
>> >> > >>>> proxyClasses );
>> >> > >>>> > > >> >
>> >> > >>>> > > >> > why <T>if ObjectProvider
is not ObjectProvider<T> (same
>> for
>> >> > >>>> Object
>> >> > >>>> > for
>> >> > >>>> > > >> > others method). basically
T isn't matched.
>> >> > >>>> > > >> >
>> >> > >>>> > > >>
>> >> > >>>> > > >> I'll have to take a look.  I believe
the <T> is there for
>> >> > >>>> "syntactic
>> >> > >>>> > > >> sugar", since you can pass in any
classes you want really.
>> >> > >>>>  Hopefully
>> >> > >>>> > > >> the user won't do something stupid
and they'll actually
>> pass
>> >> > >>>> Class<T>
>> >> > >>>> > > >> as one of the proxyClasses when
they're asking for a
>> return
>> >> > type
>> >> > >>>> of
>> >> > >>>> > > >> <T> back.  Since you can
have multiple proxy classes, the
>> >> > >>>> > > >> ObjectProvider can't really match
any one particular one
>> (it
>> >> > >>>> needs to
>> >> > >>>> > > >> support all).
>> >> > >>>> > > >>
>> >> > >>>> > > >> > 3) the jdk implementation
uses InvocationHandler for the
>> >> > >>>> proxying,
>> >> > >>>> > asm
>> >> > >>>> > > >> > implementation has almost
the same (i didn't check but i
>> >> > started
>> >> > >>>> > from
>> >> > >>>> > > an
>> >> > >>>> > > >> > exact copy), it would be great
to get them in a common
>> >> > module to
>> >> > >>>> > > avoid to
>> >> > >>>> > > >> > duplicate it
>> >> > >>>> > > >> >
>> >> > >>>> > > >>
>> >> > >>>> > > >> We have our own interface for InvocationHander,
it's
>> called
>> >> > >>>> Invoker.
>> >> > >>>> > > >> Other libraries can be "adapted"
to ours if you want to
>> reuse
>> >> > >>>> > > >> something.
>> >> > >>>> > > >>
>> >> > >>>> > > >>
>> >> > >>>>
>> >> ---------------------------------------------------------------------
>> >> > >>>> > > >> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> >> > >>>> > > >> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> > >>>> > > >>
>> >> > >>>> > > >>
>> >> > >>>> > >
>> >> > >>>> > >
>> >> > ---------------------------------------------------------------------
>> >> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> >> > >>>> > >
>> >> > >>>> > >
>> >> > >>>> >
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message