I suppose I could present on it if there's call for it...
Basically in order of speed:
array
structure
list
Now... because they do different things, obviously that
can't really be quite an apples to apples comparison... So
to give a realistic example:
<cfset mystruct = structnew()>
<cfset mystruct["yes"] = "blah">
<cfset mystruct["no"] = "not blah">
<cfset myarray = arraynew(1)>
<cfset myarray[1] = "blah">
<cfset myarray[2] = "not blah">
<cfset mylist = "blah,not blah">
Given any of these 3 structures it's possible to return
either "blah" or "not blah" from the structure with array,
structure or list logic. It will be most efficient to use
myarray[x], next fastest to use mystruct[yesnoformat(x)] and
least efficient to use listgetat(mystring,x).
Given that, array loops are going to be somewhat more
efficient than list loops.
That doesn't necessarily mean you should stop using lists --
they may not be inneficient enough in most cases to make
converting them all to arrays a worthwhile task. But if you
have an app under heavy load and you need to shave off a few
seconds here and there, that may be a good place to start.
Now if you need to find a given value in a collection of
strings, the list is going to be faster than the array, for
instance, <cfset x = listfind(mylist,myvalue)> is always
going to be faster than
<cfloop index="x" from="1" to="#arraylen(myarray)#">
<cfif myarray[x] is myvalue><cfbreak></cfif>
</cfloop>
Structures are _great_ for storing "maps". For instance, if
you've got a collection of some other variable type
(strings, arrays, queries or more structures) and in any
given case you know you'll need one but only one of them,
you can store them all in a structure by name. The names
(the structure keys) can be anything -- primary keys from
your database, file names, absolute file paths, etc. Take
for instance, the database management code in the onTap
framework which allows you to programmatically manage
multiple databases in the same cf application.
<cfset request.tap.dsn = structnew()>
<cfset request.tap.dsn.primary = structnew()>
<cfset request.tap.dsn.primary.datasource = "mydsn">
<cfset request.tap.dsn.primary.username = "mydsnusername">
<cfset request.tap.dsn.primary.password = "mydsnpassword">
<cfset request.tap.dsn.forum = structnew()>
<cfset request.tap.dsn.forum.datasource = "mydsn">
<cfset request.tap.dsn.forum.username = "mydsnusername">
<cfset request.tap.dsn.forum.password = "mydsnpassword">
Once these are declared (in the application.cfm stage of a
request) then all my database access is done through a
custom tag, like so:
<cfmodule template="#request.tapi.dba('getuserlist')#"
dsn="primary">
<cfmodule template="#request.tapi.dba('getmessages')#"
dsn="forum">
The custom tags in the /dba/ directory (which are returned
by the request.tapi.dba() function) automatically get their
datasource, username and password attributes from the
sturcture like this:
<cfset structappend(attributes,request.tap.dsn[attributes.ds
n],false)>
Which says basically, "go to the structure request.tap.dsn
and return from that structure all the attributes in the
sub-structure matching the name I passed in the dsn
attribute and don't overwrite any of my attributes". Which
also allows you to override the attributes in the dsn
structure by explicitly declaring them in the custom tag if
you need to -- although the best practice is to allow the
structure to populate them. The "map" I referred to earlier
is the request.tap.dsn[attributes.dsn] bit.
Or perhaps a better example:
Say you wanted to cache deserialized xml information from
stored templates... You could store the xml data in a
structure in the array scope with the key being the absolute
file path. Use a UDF to make sure the file path is always
the same (removing duplicate // or \/ or /\ entries in the
path, etc) then deserialize your xml, and store it in your
structure like this:
<cfset server.xmldata[attributes.file] = myxmldata>
When you need that xml data, first check the structure
<cfif not structkeyexists(server.xmldata,attributes.file)>
<cffile action="read" file="#attributes.file#"
variable="temp">
<cfset myxmldata = xmlparse(temp)>
<cfset server.xmldata[attributes.file] = myxmldata>
</cfif>
<cfreturn server.xmldata[attributes.file]>
This has the added benefit of caching your parsed xml which
is much faster than parsing it each time it's needed.
There's also a custom tag that does this in the onTap
framework -- although I'm pretty sure the xml-write feature
needs work. The read portion should be good to go tho. :)
In any event, I hope this is somewhat helpful and not too
long. :)
s. isaac dealey 972-490-6624
team macromedia volunteer
http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
> Do you have a list of general efficiency rules regarding
> arrays, loops,
> lists, structures etc? I would be interested in seeing if
> my code
> tendencies are in line. Might be a good presentation
> topic.
> Thanks -
> Tom
> -----Original Message-----
> From: S.Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 13, 2003 7:08 PM
> To: [EMAIL PROTECTED]
> Subject: The New Faster ColdFusion was RE: RE:
> Presentation Files
>> Anyways, I was curious since I've read some really good
>> reviews about
>> MX6.1. I created a test application which was a simple
>> query output, oh
>> of about 106,943 records. I limited the records to
>> 37,262, odd I know,
>> and ran the application on 2 servers, CF5.0 and CFMX6.1.
>> CF5.0 ran the
>> application in 26 seconds and CFMX6.1 ran it in 7
>> seconds.
>> Correct if
>> I'm wrong, but that's a significant change in speed!
> The first-run issue in previous versions of CFMX were a
> result of a 2-pass cfml parser which converts to java
> class
> files on the first pass and then uses the standard Java
> mechanism for converting those java class files into java
> byte code. With Red Sky (MX 6.1) they've done two things.
> The first is that they've changed the underlying Java
> Runtime Environment (JRE) to... 1.4.2 ... I think... Don't
> remember for certain, in any event, the new JRE is
> inherently faster (and iirc they said also more stable)
> than
> the JRE in previous versions of MX (up to updater 3). In
> addition, they've removed the old 2-pass cfml parser and
> replaced it with a single-pass cfml parser which goes
> straight from cfml to java byte code without stopping to
> create class files along the way (which is what caused the
> first run issue).
> The end result is that CFMX 6.1 is faster than previous
> versions of CFMX in all cases and faster than CF5 in many.
> Of course, ymmv because certain types of processes may be
> handled differently on CF5 than on CFMX (6.1 or otherwise)
> so something that worked great for efficiency on CF5 may
> not
> work well on CFMX and vice versa. Although if you just
> apply
> _general_ efficiency rules as regards things like arrays,
> loops, lists, structures etc. you're liable to get better
> performance out of CFMX 6.1 than CF5.
> So no, you're not going crazy, it really is faster. :)
> s. isaac dealey 972-490-6624
> team macromedia volunteer
> http://www.macromedia.com/go/team
> chief architect, tapestry cms http://products.turnkey.to
> onTap is open source http://www.turnkey.to/ontap
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
> Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
> Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
