I've been a little gun shy about posting recently. I stopped responding to a post about the use of the This scope. I did not follow up on the arguments for/against my actions with Mach-II. I did not follow up on anything because I got some rather negative feedback from people I respect. Their main argument basically came down to me looking bad because I was advocating altering a framework for perceived optimization.

This is my response on the matter, and if it gets me into more trouble, then so be it. The client I was working for was moving from ColdFusion to ASP. They were running on ColdFusion MX 6.1 and were not going to upgrade. They had a Mach-II application that had 363 method calls per page (213 mach II and 150 non-Mach II), which should not be the case. They were experiencing a HUGE delay per page for more than one or two people at a time and needed it fixed NOW. Yes, I altered Mach-II, along with other code, and it had a positive effect.

Were the number of method calls normal for a Mach-II application? Probably not. If any application used that many method calls, the writer would be shot, so this had to be an abnormal case. Would my alterations show any real speed increase in a well-designed Mach-II application? Again, probably not. I expect that a well-designed Mach-II application would use far fewer method calls and the total savings from the changes I made should be negligable. There are still a few places in Mach-II where I see possible improvements, and these have been sent to the Mach-II team for official review and inclusion. Will they have significant savings? See my answer above.

In the case I mentioned above, the client was happy and the contract was fulfilled. Would I do it again? Definitely! Why?

Because I'm an employee. So are you. We work for someone. We can offer our suggestions to them, let them know what we've seen and heard and try to move them towards proper code and procedures, but at the end of the day we are just employees. The client is always right, and if we feel otherwise, we can either suck it up or get a new client.

I get called in on emergency contracts all the time. When something is going wrong and it needs to be fixed immediately, then I get the call. For the client mentioned above, it required a fast and dirty fix. For another client, it required a fast fix for their "memory build and crash" problem and then an analysis of how to fix it. Sometimes the analysis leads to suggestions that 'break' OOP, but the end result is always the same. Better code for better performance.

Do I disrespect frameworks? Not at all. I'm one of the founders of the Fusebox framework (a methodology at the time). Do I advocate altering frameworks directly? My last post stated quite clearly that I do not feel that a framework should be altered except by those that know what's going on. On the other hand, if you know what's actually happening in the framework, feel free to alter it. But if you do, realize that you are essentially "forking" the framework, and any upgrades made to the framework cannot be reflected in your code unless you make some hands-on alterations.

But that's the beautiful thing of open source. Anyone can fork it. Anyone can remove the parts they don't want or need in order to tailor the code to their use.

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!