Blog

There has been a lot of talk recently about design patterns aimed at circumventing the overhead ColdFusion imposes upon us when creating CFCs. I'm not sure who coined the term "Object Instantiation Penalty", but the first reference to it I can find in the CF community was over at the Dot Matrix blog. Everyone seems to agree that object creation in ColdFusion leaves something to be desired, but I haven't seen anyone really quantify the price yet. I decided some line charts were in order.

I've been staring at my computer monitor trying start this paragraph for about 10 minutes now, so I'm just going to start typing. I've been thinking about system design. Organization versus performance. Design patterns versus efficiency. We adopt some code without thought to its performance because we're talking about milliseconds, and the readability, organization, and structure gains our apps enjoy are well worth it. I'm not sure that is always the case though, and we don't notice it until too late.

On my home PC I have the developer edition of ColdFusion 8 installed along with Apache Web Server and MySQL 5. Apache and MySQL are pretty lightweight, but ColdFusion can get a little bulky when it comes to memory. I don't use my personal Dev sites all the time, so I like to turn it all off when I'm not using it. I only have 1 gig of RAM in this PC after all.

I love infinite loops. They're sort of the black hole of programming. No one really knows what you code does when it reaches the last iteration of an infinite loop, but I speculate it has something to do with String Theory and unbounded time and space increasing proportionately to the rate of dense matter being compressed by gravitational forces so strong even light can't escape. Well, that's what I came up with off the top of my head anyway. Speaking of infinite loops, I found one happening on my server today.

I ran into an interesting behavior with MySQL this week. I was helping someone speed up a slow page and a sizable increase in performance was achieved by simply re-arranging the SQL statement. The page was calling a SQL statement inside of a loop-- probably around 150 times on a page load. My initial idea (and still the best long-term one I think) was to gather all the information from the database in a single cfquery and not hit the database over and over. That approach would have required quite a lot more refactoring of code, so first we tried to squeeze some better performance out of the SQL already being called.

I generally don't care to write about topics that have already had the stuffing blogged out of them. However, I've still seen some of these questions floating around and I figure it never hurts to have more than one place on the 'net talking about it. The two things I wanted to cover real quick are how cfqueryparam may (or may not) enhance the performance of your queries. Also, when does criteria in a query NOT need a cfqueryparam.

Some time ago while working in cfscript I had the need to cfparam a bunch of variables. I was building an XML document out of form fields and a number of the fields wouldn't always exist. At first I made a simple UDF to encapsulate a cfparam tag, but it this code was inside of a loop that beat it over and over again before it was finished and performance just wasn't cutting it. The culprit as it seemed was scope hunting.

The past couple of days I've been messing around with a couple functions, cleaning them up a bit to blog about them. One of them is for color-coding SQL and the other for highlighting differences in two strings. Both are pretty small, but very repetitive in what they do. Depending on the size of the text you are processing, performance varied. Sometimes the code inside was repeated hundreds of thousands of times given a large enough test.