excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [RT] About proxies and pooling
Date Fri, 25 Jun 2004 13:32:09 GMT
Carsten Ziegeler wrote:

> Berin Loritsch  wrote:
>>>Hmm, just curious. If we would create BCEL proxies wouldn't
>>>the performance problem go away?
>>There is BCEL proxy generating code in there already (still some
>>minor issues, but decent enough).
>>The BCEL code was significantly faster than reflection based
>>dynamic proxies, but there is still a considerable overhead to
>>BCEL proxies.  I can't remember if the price was 5 to 1 or 3 to 1
>>for the BCEL proxies.
> Ok, I have not looked at the BCEL code yet, but my thought was that it
> works this way:
> Imagine you have an interface A with one method do(), you create
> a proxy that implements interface A as well, holds a reference to
> the wrapped component and calls inside its own do() method,
> simply the do() method of the wrapped object.
> Is it this way? If so, I wouldn't understand the performance problem :)

This is the rough equivalent of what BCEL generates:

class BCELGeneratedProxy implements A
     private final A m_proxy;

     public BCELGeneratedProxy(A proxy)
         m_proxy = proxy;

     public void do()

Do keep in mind that there is a heavy penalty for creating classes with
BCEL due to the class compilation time.  There is still a penalty
involved with the wrapper class.  I'm not sure if it is because hotspot
is not recompiling or inlining it or if there is some other technical
issue I am not aware of.  I will say that BCEL programming is a royal
pain.  While I believe this is what is happening, there could be some
gotchas that I am not aware of that sap the performance.


"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook

To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message