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!