Hello Craig,
Interesting question and clear answer... 8)
What do you think about such caching for Class? With this approach we
call forName() method only once - no other overhead.
public class EntityMapping {
protected Class cach = null;
protected String type = null;
public String getType() {
return type;
}
public void setType( String type ) {
this.type = type;
}
public Class getStub() throws ClassNotFoundException {
if( cach!=null )
cach = Class.forName( type );
return cach;
}
public Entity getEntity() throws ClassNotFoundException {
return getStub().newInstance();
}
}
Wednesday, June 20, 2001, 12:31:03 AM, you wrote:
CRM> On Tue, 19 Jun 2001 [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> Is anyone using the STRUTS framework in a production environment yet?
>>
>> We're currently developing a MVC based webapp and are looking at
>> potentially taking a step backwards and basing it around STRUTS. One area
>> of concern is the dynamic creation of the Action objects using 'forName'.
>> What sort of performance hit does this give?
>>
>> Advice from our Tech Architect at the moment seems to be to look at STRUTS
>> but write our own version and he's not too keen on 'forName' processing.
>> Is this an unfounded concern?
>>
CRM> There are several considerations to think about in trying to address this
CRM> concern:
CRM> * How often does it happen? In Struts, objects are created
CRM> dynamically only under the following circumstances:
CRM> - The first time a particular Action class is accessed (so it's not
CRM> really relevant to discussions about performance impacts).
CRM> - When you are a using form bean, AND the form bean does not already
CRM> exist in appropriate scope. If you adopt a pure MVC approach (and
CRM> flow all your requests through the controller), you can easily
CRM> arrange to create form bean instances from a recyclable pool if
CRM> you want to.
CRM> * Does it matter when it does happen? One of the most striking
CRM> differences between modern HotSpot-based JVMs and earlier generations
CRM> is that the cost of object creation (and the subsequent garbage
CRM> collection) has been dramatically reduced. I have had people who are
CRM> pretty sharp tell me that object pooling can easily cost you more
CRM> performance than it saves by avoiding object creations, in many
CRM> circumstances.
CRM> * Is it worth the cost? The point of many features of Struts (or any
CRM> other application framework) is to accelerate development, and to
CRM> reduce ongoing maintenance costs by making your architecture naturally
CRM> easier to maintain. Is this worth throwing a little extra hardware
CRM> at the server to deal with any perceived "overhead" of object creation?
CRM> For many people, the answer is "yes, absolutely". And projections for
CRM> the future cost of a developer's time, as compared to the cost of
CRM> "x" MIPs worth of CPU time, is going to make this even more attractive.
CRM> As you can see, there's no cut-and-dried answer. Dynamic object creation
CRM> has a cost (which can be mitigated in your application design). So does
CRM> introspection to do the BeanUtils.populate() trick of copying request
CRM> parameters into bean properties (which vastly reduces the work needed to
CRM> create and maintain form bean classes). Like everything, it's a balance
CRM> of cost versus benefit. And the benefits can be quite dramatic.
>> Regards,
>>
CRM> Craig McClanahan
--
Best regards,
Oleg mailto:[EMAIL PROTECTED]
