struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: Performance, Reflection, and Object Creation vs. Cacheing
Date Tue, 28 Aug 2001 13:45:34 GMT
People I trust have said that they have run benchmarks that say
can cost 5% to 10% more than direct method invocation.

Now this is enough for some maven to put it on an optimization
along with unrolling loops, and other time vs space trade-offs. But, 
personally, I don't find the need to unroll many loops in the
I write ;-)

So it's important to ask yourself whether 5% to 10% is a difference that 
makes a difference?

Also remember that in a real application, we are looking at one 
utility method, like BeanUtils.populate(), being threaded with all the 
assignments. I would think this is much more efficient than loading 
several hundred "optimized" methods just to manage direct method
BeanUtils.populate() also caches the descriptors so subsequent calls are 
even cheaper than the first.

Real-life optimizations are differences that make a real difference.
the EJB platform was being designed, object creation ~did~ make a 
difference, and caching ~was~ vital. To an extent it still is, 
especially with deep hierarchies, like those many EJB applications 
find themselves using. But object creation and garbage collection in a
model JVM is not what it used to be ;-) Progress!

Meanwhile, personally, I've started to build calls to
into my own data transfer utilities. This lets me put a call deep inside
the resource layer that neatly turns an arbitrary ResultSet into a 
collection of arbitrary beans. It just matches the rset columns with the 
jbean properties.

// Transfer ResultSet to Collection of target beans **
if (resultSet!=null) {
	collection = ResultSetUtils.getCollection(

Where ResultSetUtils does this 

    public static void populate(Object bean,
                                ResultSet resultSet)
        throws SQLException {
        // Build a list of relevant column properties from this
        HashMap properties = new HashMap();
        // Acquire resultSet MetaData
        ResultSetMetaData metaData = resultSet.getMetaData();
        int cols = metaData.getColumnCount();
        // Scroll to next record and pump into hashmap
        if ( for (int i=1; i<=cols ; i++) {
            // :TODO: Let native types through
            int type = metaData.getType(i);
            if ...
        // Set the corresponding properties of our bean
        try {
            BeanUtils.populate(bean, properties);
        } catch (Exception e) {
            throw new SQLException("BeanUtils.populate threw " +

This can save hundreds of lines of code that would have otherwise have
needed to write custom transfer utilities. (Been there, did that, not

Of course, it works with more than just ResultSets. I wrote a similar
of utilities last week that turned a Lucene Hits list into a collection 
of beans. Sweet ;-)

Here are some other links from this list:

Other background links:

Today's quote:

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil." - Donald Knuth


Bryan Field-Elliot wrote:
> This is incredibly important stuff! I'm sick to death of making tons of
> EJB entity beans, and then "Value Objects" (or data objects) which are
> very similar, and with Struts, "Form Beans" which again are very
> similar. Often I wish I could just use generic property sets (using
> HashMap, or any other generic collection). But I have resisted on
> principle, because I thought it would be a poor performer compared to
> "straight Java" variables and getters and setters. But here you are
> saying "reflection is no longer a point of concern". What information
> have you got in this regard?
> Also, you go on to say 'ditto for objection creation", and that it's
> "more expensive to cache an object than recreate it". Where are you
> getting this information? It goes against the design considerations of
> virtually every "highly optimized" Java system I've seen, including EJB
> which goes to EXTREME lengths to reuse rather than recreate. You see the
> same pattern with JSP custom tags (nowadays they are pooled), and you
> even see the same thing in the Servlet spec design (which is to have one
> multithreaded instance of the servlet class, rather than one per user
> which would make more logical sense).
> So, my apologies if this is off-topic of Struts, but these seem like
> very important and impactful design issues, relevent (even if
> peripherally) to good Struts design and development.
> Thanks,
> Bryan

View raw message