There has been a lot of interest in the steps I took to optimize my client's website. The main interest was in what I did to Mach II in order to speed it up, especially as Mach II is rather optimized to start with. The answer is to cheat.

If you look at the Mach II code you'll see that it's rather complex. It's also 1000% legal. Every component is documented as is every cfcomponent and cffunction tag. Output="False" is used everywhere needed, access is always defined, every cffunction tag has a returntype and every cfargument tag has both a type and a required when needed. It is this attention to detail and legality that gives Mach II and every other CFC based framework it's unexpected overhead.

Let's start with the cffunction tag. The returntype attribute performs a data validation on the information being returned from the function. Any validation operation has a certain amount of overhead and when the validation is done against a component reference then the overhead becomes more noticable. In addition, I find the returntype to almost be an insult. If I wrote the function then I should have a relative clue as to what it is returning. If the returntype is only being used for documentation rather than for actual validation, then that information can be put in the hint.

But wait! I'm not saying to remove the returntype. It is actually rather important to the operation of a function. What it does beyond data validation is tell ColdFusion IF the function is returning anything. For this reason I always have a returntype defined but its value will either be any or void. Any basically tells ColdFusion that the function is returning something but that it should not worry about validating it. Void tells ColdFusion that the function will not return anything at all. If a cfreturn tag is used within the function then an error is thrown.

The removal of the returntype alone causes a noticable speed increase for components that are heavily used. If we take the same idea of removing data validation and apply it to cfargument tags then we'll see even more of an improvement. There are actually 2 different types of data validation going on in a cfargument tag. The first is the same data type validation as defined above and this is defined by the type attribute. The second is a check for existance and is defined by the required attribute. The total removal of both of these attributes increases the savings we get from the removal of the returntype. I do one additional thing, though. I add a hint attribute to the tag, which will tell me what data type was expected and if it was required. This is for documentation purposes only, but does help when debugging.

The removal of the type and/or required attributes from the cfargument tags is not without consequences. There are times where a function needs to be sure of the data being passed in. I judge these on a case by case basis, but when it comes to Mach II I didn't even bother. Mach II is so solid in its construction that every function is very exact in what gets passed to and from it.

As a final warning, remember that Mach II is a closed system that has been heavily tested and is only modified by a select few. No one is supposed to be touching the core code other than those select few. Because of this strict control, I felt very confident in my alterations and they worked flawlessly. In the end thats all that matters to a client...has the job been done.

I was doing a remote presentation last night on "Object Orienter Programming for ColdFusion Developers" and it eventually moved over to the topic of optimizing ColdFusion Components. While I was showing what I do for speed, I relayed a story about a client of mine who is using Mach II. I was brought in to speed up the clients site which was timing out on a regular basis.

After a review, I found some places that could be optimized and one major place was the Mach II code. I rebuilt most of it and the time savings was immense. Of course, in order to make it faster I had to cheat and break many of the accepted 'rules' of OOP and CFCs. Not something that I suggest anyone doing without a full understanding of the how and why of it (which I'll talk about another time).

After telling the story and showing what I did, someone assumed that I did not like Mach II and asked what Framework I used. I quickly corrected his conclusion and told him not only do I have nothing against Mach II, but it's a really well thought out and solid framework. I don't use it because I don't use any of the public frameworks. I'm obsessed with optimizing my code for speed and performance and really optimal code doesn't go hand in hand with frameworks. On the other hand, I stressed that using a framework is a MUST in almost all situations and that people should not go my route unless they really know what they're doing and have very strict control over who has access to their code.

Bottom line is that unless your a paranoid, obsessive, hermit programmer, use a framework!

Waaaay back in 2000, I wrote an article on certain 'laws' of ColdFusion that I used: The Law (according to Michael Dinowitz)

One part of this article was a rundown of what I called Execution Functions. Basically, these were functions that either returned no value or a boolean to indicate success of failure. My 'hard' rule is that there is no need to assign the value returned from these functions to a variable and even that doing so is a waste of memory. I've rewritten that section many times in different places, but this is what is actually happening.

A CFSET tag is divided into 2 parts. One part is the evaluation zone, which is the right hand side of the tag after the equal sign (if an equal sign exists). The evaluation zone will treat anything that is not a number or a string as something to be evaluated. It will also look inside any string for anything surrounded by pound signs and try to evaluate it as well. This zone is a general evaluation zone, so you can even use something like:

This is a comparison which you may see in a CFIF, but will evaluate properly inside the CFSET. If the name variable has a value of "Michael", then the value of IsName will be Yes. Otherwise it will be No.

For an even older article that clearly explains evaluation zones, look here: Evaluation in ColdFusion

The other part of the CFSET tag is the variable assignment. This is a variable name followed by an equal sign and will accept whatever comes from the evaluation zone and assign it to variable. This area is TOTALLY OPTIONAL. There has never been a need to assign the value of the evaluation zone to a variable and doing so basically creates a variable that is usually useless.

So bottom line is that any CF function, UDF, or Component method call (which is basically a UDF) can be used in a CFSET without any variable assignment.

This is what I do and every time I see some code that is running a QuerySetCell() and assigning it to a temp variable, it's the first thing I erase.

You know, I really have to update and republish a lot of my old articles. Lots of good information just buried under the weight of time. :)