Stake Five

Artist’s impression of Ray nuking Ashwin ;-)

If it talks like a duck and walks like a duck, then it must be a duck… and, apparently, it’ll waddle a good deal faster than a turkey, or any other non-duck species.

I’ve been meaning to get to the subject of duck typing and performance ever since I saw Sean give his presentation at CFUnited. Unfortunately, the performance aspect of going duck was what caught most people’s attention; as Sean shouts out duck typing is not about performance.

I finally got round to downloading Sean’s source code and ran some tests of my own. Here’s the low-down - performance is affected only when the argument type or return type is specified as a CFC; if it is anything else, performance is about equal to the duck typed equivalents. If you’re typing arguments and return values to structs, arrays, strings, numbers, whatever, duck typing will not give you any performance gains. Apologies all if I’m repeating what’s already been pointed out; I searched around a bit and couldn’t find anyone else commenting on this particular detail.

CFC type checking is always going to be more expensive than checking any other type, since we need to jump through many of the same hoops as we do during createObject() to actually resolve the path to the CFC template - is the path to type being checked relative or absolute? Is it referenced via a mapping? Is the type being checked a supertype of the type passed in? You get the idea; evaluating these kinds of complex relationships is expensive.

So do duck type if your design calls for it, or if you’re having serious performance problems with code that checks for CFC types. Otherwise, make like a monkey and code!

Update: You can download the code I used for testing here. It’s identical to Sean’s code, with the exception of a new typedNative function in performance.cfm, which is used to test for “native” types, i.e., Struct, Array, whatever.

… no server (or language, or platform, or all of the above!) has gone before?

Much fuss has been made over CF not being an enterprise platform. All too often, it would seem, we’re the poor kids who get the ‘lite’ projects. Why is this?

I will concede that some of the fault lies with the product. There are long standing requests such as CFC serialization that have yet to be addressed. There are performance issues that have been found with CFSWITCH, string concatenation and other areas of the server.

So I’d like to ask all of you - what’s your number 1 problem that stops you from being able to sell CF up to your management/customers as an “enterprise” grade solution? Leave your comments here, and I promise they’ll be looked into.

At the same time, I think we as a community have some work to do as well. How do we change the impression that CF is not an enterprise platform? There is a problem to CF being such an easy language to learn, with so much power packed into individual tags; it’s just as easy to abuse that power as it is to use it. Could CF provide more checks and balances to ensure that this does not happen? Perhaps, but definitely not in every case.

So do start applying those best practices and numerous frameworks (and un-frameworks!) in your projects. Read the presentations Sean’s put up, Ben’s resources page, and the numerous CF blogs dealing with this stuff. I’m the last person to claim that the application of these best practices and patterns are easy to understand the first time round; but as you get into them, I think you’ll find that they become a habit, an integral part of the way you design and code.

On an (un)related note, the crew of the good Starship Enterprise celebrated their 40th anniversary this weekend past - happy birthday, Star Trek!

I like Spry. Why? Simple - they got their data model right.

Not that I’ve done a lot of AJAX work, but from what I’ve seen of other frameworks, it seems that the general focus has been on creating cool UI components. While this is not at all a bad thing, the result is that AJAX data models are not nearly as mature as they could be.

Continue Reading »