You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2008/03/25 21:45:33 UTC

Next possible performance target: constructors with arguments

I'm not entirely sure that I believe it, but it appears that the following
bit of spring from cxf.xml is disproportionately expensive. Why? Because it
uses a contructor with arguments. Why? Because spring has to think much
harder to decide on a constructor than a set of set methods.

So... I'm going to try adding set methods, a no-args constructor, and an
init-method, and see what I see.

If this works, I'll be on the hunt for other cases of the same (anti????)
pattern.


 <bean id="org.apache.cxf.resource.ResourceManager" class="
org.apache.cxf.bus.resource.ResourceManagerImpl">
       <constructor-arg>
            <list>
                <bean class="org.apache.cxf.resource.ClasspathResolver"/>
                <bean class="org.apache.cxf.resource.ClassLoaderResolver"/>
                <bean class="
org.apache.cxf.bus.spring.BusApplicationContextResourceResolver"/>
            </list>
       </constructor-arg>
       <property name="bus" ref="cxf"/>
    </bean>

Re: Next possible performance target: constructors with arguments

Posted by Benson Margulies <bi...@gmail.com>.

Yes, I agree, and thus the temporizing ???? on the 'anti'.

Sadly, this class stack here is resisting arrest. The default ctor
initializes. What we want is a default ctor that doesn't init, and perhaps a
lazy init later if nothing else wanders along.

On Tue, Mar 25, 2008 at 6:01 PM, Glen Mazza <gl...@verizon.net> wrote:

> I wouldn't necessarily consider it an anti-pattern.  Constructor
> injection is good when you need to document/demonstrate that a class
> must *not* be instantiated if it does not have those certain properties
> available.  Of course, that can be rolled back to just using setter
> injection in areas where performance is crucial.
>
> Glen
>
> Am Dienstag, den 25.03.2008, 16:45 -0400 schrieb Benson Margulies:
> > I'm not entirely sure that I believe it, but it appears that the
> following
> > bit of spring from cxf.xml is disproportionately expensive. Why? Because
> it
> > uses a contructor with arguments. Why? Because spring has to think much
> > harder to decide on a constructor than a set of set methods.
> >
> > So... I'm going to try adding set methods, a no-args constructor, and an
> > init-method, and see what I see.
> >
> > If this works, I'll be on the hunt for other cases of the same
> (anti????)
> > pattern.
> >
> >
> >  <bean id="org.apache.cxf.resource.ResourceManager" class="
> > org.apache.cxf.bus.resource.ResourceManagerImpl">
> >        <constructor-arg>
> >             <list>
> >                 <bean class="org.apache.cxf.resource.ClasspathResolver
> "/>
> >                 <bean class="org.apache.cxf.resource.ClassLoaderResolver
> "/>
> >                 <bean class="
> > org.apache.cxf.bus.spring.BusApplicationContextResourceResolver"/>
> >             </list>
> >        </constructor-arg>
> >        <property name="bus" ref="cxf"/>
> >     </bean>
>
>

Re: Next possible performance target: constructors with arguments

Posted by Glen Mazza <gl...@verizon.net>.

I wouldn't necessarily consider it an anti-pattern.  Constructor
injection is good when you need to document/demonstrate that a class
must *not* be instantiated if it does not have those certain properties
available.  Of course, that can be rolled back to just using setter
injection in areas where performance is crucial.

Glen

Am Dienstag, den 25.03.2008, 16:45 -0400 schrieb Benson Margulies:
> I'm not entirely sure that I believe it, but it appears that the following
> bit of spring from cxf.xml is disproportionately expensive. Why? Because it
> uses a contructor with arguments. Why? Because spring has to think much
> harder to decide on a constructor than a set of set methods.
> 
> So... I'm going to try adding set methods, a no-args constructor, and an
> init-method, and see what I see.
> 
> If this works, I'll be on the hunt for other cases of the same (anti????)
> pattern.
> 
> 
>  <bean id="org.apache.cxf.resource.ResourceManager" class="
> org.apache.cxf.bus.resource.ResourceManagerImpl">
>        <constructor-arg>
>             <list>
>                 <bean class="org.apache.cxf.resource.ClasspathResolver"/>
>                 <bean class="org.apache.cxf.resource.ClassLoaderResolver"/>
>                 <bean class="
> org.apache.cxf.bus.spring.BusApplicationContextResourceResolver"/>
>             </list>
>        </constructor-arg>
>        <property name="bus" ref="cxf"/>
>     </bean>