<soapbox> I strongly urge the "it's irrelevant" route. The specifics can be measured with some very basic testing (do it both ways, and then call the method 1000 times each way and see which is faster), but that's not the point. CF is an abstraction layer on top of Java that makes it MUCH easier to use, and by delving into the nitty gritty of that abstraction layer basically defeats the purpose of having it to begin with.
Every abstraction layer in the world makes things slower at the expence of an improved developer experience (faster coding, easier maintenance, or whatever); that's whole the point of an abstraction layer. Developers cost between 75,000 and 200,000 a year, while a new server can cost as little as 3-4,000. If you're running on one server now, you can double you're throughput for a few grand of hardware, or by spending an enormous amount of developer time optimizing. Which isn't to say you shouldn't worry about efficient code, just that trying to squeeze every drop of performance out of an application is generally a foolish thing to do. So, just write it the CF-centric way (buncha createObject calls), and assume that MM did their job with making it efficient. If, when you're doing your formal load testing, you discover that the createObject calls are a legitimate performance inhibitor, then you can worry about optimizing, but until that point, just leave it alone. </soapbox> The reason the bunch createObject method is slower is that the classes all have to be instantiated via reflection. Reflection was notoriously slow when it first came out (Java 1.2, I believe), but has improved by leaps and bounds since then. It's never going to be as fast as a compiled-in class reference (what you'd get if you did your custom Java factory class), but the different is negligible. A lot of software heavily depends on reflection in order to function; CF is far from unique in that respect. And it's not just createObject that does it, I'll virtually guarantee that every single CF template (with UDFs/method counting as separate templates) that you call is invoked using reflection. In other words, there's an enormous amount of it going on already, so the cost of a couple more uses is going to be insignificant. cheers, barneyb On 4/29/05, Z H <[EMAIL PROTECTED]> wrote: > I have a function that creates multiple Java objects on CFMX 6.1 Enterprise > environment. My question is which scenario, if either, is more efficient? > Creating multiple Java objects, then working with them in a CFScript > OR > Writing my own Java class file that instatiates multiple objects and > then referencing my new class to create one object in a CFScript? > > I was under the assumption that since MX compiles my function into a class > file for execution, it would essentially be the same thing, but others have > argued with me that this is not the case. Can anyone clear > this issue up for me? > > Thanks- > NoNo > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:205186 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
