It sounds like you are passing data (in the form of XML) to the CFCs
as you initialize them.
I think the important thing to consider is how current you need that
data to be. For example, I have a system with several CFCs. The
instantiation data for most of them is relatively static data
(datasource information rather than page information or database
data, for example).
Given that, I am able to safely instantiate them into Application
scope only if they don't exist or I decide they need to be
instantiated again (a relatively rare occurrence).
This saves me the performance hit of having to instantiate several
CFCs on every page request. The one drawback is that my instantiation
cost is pretty heavy. If I restart the server, it takes about 20
seconds for the first page to load. After that, however, the system
runs pretty smoothly.
You may find that some of your CFCs can be cached effectively in this
way, avoiding the CreateObject hit to some degree,
I have read that removing type checking will improve performance, but
I can't speak to the degree to which that will have an effect.
I am sure others on this list will have other ideas for improving
performance as well.
Good luck!
Steve Bryant
918-449-9440
Bryant Web Consulting LLC
http://www.BryantWebConsulting.com/
http://steve.coldfusionjournal.com/
At 09:55 AM 11/22/2006, Ed Griffiths 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]
