If you're deploying on Windows and IIS, you may want to consider BlueDragon.NET. It's much faster than CFMX, especially in the areas of CFC creation and XML processing. As I mentioned in this blog entry, one of our customers (Alex Skinner of Pixl8, who presented at CFDevCon recently), is reporting page execution times that are more than 5 times faster on BD.NET than CFMX:
http://blog.newatlanta.com/index.cfm?mode=entry&entry=12DF8205-7165-CD5A-7EF 6133E289C4A9E You can download BD 7.0 beta1 here, though you might want to wait for beta2, which will be released on Monday, Nov 27 (at the same URL): http://www.newatlanta.com/c/products/bluedragon-beta/download/home The final release of BD 7.0 is planned for Jan 2007. Or, you can download BD 6.2.1 from here: http://www.newatlanta.com/c/products/bluedragon/download/home Vince Bonfanti New Atlanta Communications, LLC http://www.newatlanta.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ed Griffiths > Sent: Wednesday, November 22, 2006 10:55 AM > To: [email protected] > Subject: [CFCDEV] Improving createObject() / CFC-driven > system performance > > 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]
