Re: Performance, Reflection, and Object Creation vs. Cacheing(was: Barracuda talk)

[Calvin Yu]

On Tue, 2001-08-28 at 00:02, Bryan Field-Elliot wrote:

 
 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).

Object creation is rather fast, but that doesn't mean caching is always
frowned upon.  Caching for performance at the enterprise level is really
to reduce object initialization rather than object creation.  The
problem with EJBs, Tags, and Servlets is that they potentially do a lot
of up front initialization.  All three has to at least read an XML to
load some kind of deployment information, and then there are resources
(db, networking) that can be allocated by containers or developers.
Struts objects generally don't a lot of object initialization, therefore
isn't necessarily a really good candidate for caching.


Calvin

Performance, Reflection, and Object Creation vs. Cacheing (was: Barracuda talk)

[Bryan Field-Elliot]

Ted,

I read your rebuttal tonight re: Barracuda, and I have questions about 
one of your points. Actually this has nothing to do with Barracuda:


-

Reflection

Every recent report I've seen says reflection is no longer a point of
concern. Ditto for object creation and garbage collection. The latest
advice is that is can be more expensive to cache an object that recreate
it.

-

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