The only thing that comes to mind that you didn't mention is an iterating object in place of multiple objects. The iterating object has the same methods of an independent object but holds the info for each "object" in an array, query object or some other data structure and gives a way to iterate over the information it holds using methods like next, previous, id, etc. This then requires only one object to be created. Not sure if this would work for your app without knowing more but thought I'd throw that out there.
On 11/22/06, Ed Griffiths <[EMAIL PROTECTED]> wrote:
Hi Can anyone suggest alternatives for improving CFC object creation performance? The scenario: we've developed an entirely CFC-driven system that builds large XML strings on the fly. The XML is read by a Java application that uses the XML data to build GUI interfaces. This system uses a series of core CFCs, one per GUI interface widget (labels, tabs, buttons, text boxes etc). These core CFCs use recursion to wrap interface widget nodes into a valid XML document structure. These core widget CFCs are called via another set of CFCs that use CF's createObject() syntax to build XML for entire GUIs. Every interface-building CFC contains a series of GUI 'page' methods: each method creates between 1 and 100 interface widget CFC objects. It's an elegant system that addresses all our requirements except one: it's very slow (several seconds to return a response). We've already optimised our database calls and table structures, and optimised string operations to use cfsavecontent instead of basic CF '&' string concatenation (guess it must use stringBuffers under the hood?). We've implemented cflog logging within each CFC method to provide performance metrics: the bottleneck is createObject(). Currently all of our CFCs are typed, we use type checking, and create each object from scratch. Workarounds we've considered include turning off type checking/specifying returntype=any, and creating a pool of empty objects in, say, the server scope rather than calling createObject each time we need a widget. Does anyone with experience with large CFC-driven systems have any specific recommendations for improving performance? Thanks in advance, Ed You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
