So today I tried to cfdump something to see what was available for methods and data, but when I'd run the code with the cfdump in place, I would get:

Remove the cfdump, things worked fine. Add it back in, get the error. I restarted the server, no good. So I googled. And I found something!! Google knows all, Google sees all.

Strangest freaking error message and behavior evar!

But, thanks to Microsoft via Brian Kotek through Ray Camden, I got the right idea... but the technote was for the wrong version of windows. Back to Google, Sauron's Eye of the Interwebs, and behold, an answer on Microsoft Answers.

Once you've issued the command-line bits you'll need to restart your J2EE server... but boom... it all worked!

And for those hearty souls that like the nitty-gritty, here's the dope on this issue.

UPDATE: OK, so it turns out I should have read the comments on Ray's blog entry, because the link status detect didn't fix the issue. Turns out it's a result of EHCache trying to use multicast (yes, that'd be UDP) over VPN... apparently notoriously unsupported but breaks CF's default EHCache settings. So, the solution is fairly simple, really...

Edit {jrun_home}/servers/{server_name}/cfusion.ear/cfusion.war/WEB-INF/cfusion/lib/ehcache.xml and remark out the following two lines:

Make those changes (the lines come after descriptive comments, I just moved the comment closer down 2 lines), restart your J2EE instance and you're golden!

Either that or spend your workday in isolation, dropped off VPN! lol

So this morning while I waited for a Subversion update to complete (large repos across VPN suck by the way), I was cruising the JavaDocs for the javax and java.lang packages. Why? Cuz I'm a geek... dude, that should be obvious. HELLO!

Anyway, I was clicking here and clicking there and finding things generally interesting... when I suddenly found myself reading the description of a class very thoroughly. Why? Because (as the title may have betrayed) it was the one of the more enlightening, most concise explanation of heap space, non-heap space and garbage collection I've read... to date. And I've been at this for a while now.

Ironic, to find something like that hidden in the JavaDocs for java.lang.MemoryMXBean of all places.

Here's the link. Give it a read and let me know what you think...

Laterz!

In a conversation that came up during a meeting today, there was some discussion as to whether or not ColdFusion 9's beefed-up CF Script support included rethrow. Next thing you know a few of us dash off to test it.

Turns out it supports it as a statement. Also turns out that it's not mentioned in the ColdFusion 9 documentation, at least not in the sections that act as documentation for CF Script. Sadly, the whole CF Script section of the Developer's Guide kinda sucks and in the language reference (actually referred to as the CFML Language Reference) it's not mentioned outside the tag, and that just has a link to the Developer's Guide.

Blog time! So...

It works. And I also discovered a way of using it that I'd never thought of before. If you have a catch statement that does some things like logging or an alternate behavior or something, but then you want to return the flow to the built-in error handlers, you can do it like this:

I've only ever used it in CFCs where I was going to have deep composition and I wanted to be sure that a particular error was going to be the one that was seen. It changes where the error gets reported from, locally where the code is executing or from the caller's perspective. Without rethrow, the error will usually be reported from the caller's perspective instead local to the running code.

Happy throwing...

Laterz!

Alright, now for the last and final debunking of the PHP vs ColdFusion - a test against time" post by our dear PHP apologist friend Mr. Phil Parsons. I'm sure by now he's deliriously happy he bothered to post that article in the first place. One thing you have to say for ColdFusion: the fans are fierce, loyal and knowledgeable. Challenge us only if you have your ducks in a row and your thinking cap on tight. And I'm sure if I try I can mix a few more metaphors before I finally sleep tonight.

Or we could just skip to the code...

So. I started out working with 200,000 characters. I mean, what fun is it if we can't outdo PHP at its own game, eh? I managed to roll 200,000 characters from local variable into a page buffer and into a different variable in .36ms. I have NO freaking clue why this particular test is significant, but apparently it's one of the ways in which PHP is purportedly better than ColdFusion. However, I just realized something:

Mr. Parsons is running a comparable CPU to mine, however he's running it overclocked at more than 1GHz faster than my lowly (and 4-year-old) MacBook Pro. Intel Core2 Duo 2.8 GHz LAPTOP vs AMD Phenom II X2 550 3.10 GHz @ 3.83 GHz DESKTOP. I wonder how my tests would run on a DESKTOP machine running a full GHz faster than my laptop? Especially considering that in general desktops GHz for GHz perform a bit better than laptops anyway?

So I dropped my character count to 140k, just like his and guess what? My poor, humble laptop burdened with running ColdFusion in a J2EE container, PHP5, Apache, Eclipse, FireFox, and about a half-dozen other things (I currently have 24MB of RAM free, yes, 24MB) managed to run his same test in .26ms. That's .06ms slower, on hardware running a full GHz slower. So you tell me which performs better.

Really... next time you decide to take on another platform with trickery and deceit, Mr. Parsons, think twice.

And now, finally, here's the code!

Interestingly, the bigger the value in the its variable (the number of times we repeat the experiment) the FASTER OUR AVERAGE TIME IS. I just find that extremely interesting. God bless HotSpot. :)

Laterz!

I'm making sort of a series out of poking holes in the anti-ColdFusion ramblings of an admittedly biased blogger. Pro-PHP blogger Phil Parsons blogged about how ColdFusion is tragically slower than PHP and is therefore something we should all stay away from if performance is any kind of concern. Unless we want to connect to MS Exchange... maybe.

So his second example was object instantiation performance. Arguably, one of ColdFusion's weak points... but not something entirely unworkable. People who complain about this generally only do so because they don't know how to best use CFC's and, most especially, how to write them properly. Nowhere is this more apparent than in Mr. Parsons' components. If this is how he writes CFCs it's no wonder his employer has "to constantly make decisions NOT to use OO features of Coldfusion based on [sic] it's poor performance." (That quote is from his comments below the article).

You can download the source he uses in the article, so I'm not going to post that here. I will say that the primary critiques I have against them are things like the ungodly amount of white space, the silly variable creation in the pseudo-constructor and the amazing number of unnecessary expressions.

What I am going to show you is my version, and then I'll share my results.

Colony.cfc

Drone.cfc:

colony.cfm:

And now for the really bad news:

While I managed to blow his unquestionably inflated time of roughly 600ms or more right out of the water, ColdFusion continues to have a weak spot around object instantiation. The best I could do was slightly less than half of what Mr. Parsons got. I manged to get this test down to 250-300ms. Still substantially slower than the 42ms he reported for PHP. So while Mr. Parsons was grossly exaggerating the problem, the problem yet persists. Even with the drastic improvements the ColdFusion team managed to pack into ColdFusion 9.0.1 over previous versions.

The question you have to ask yourself, at that point, is whether it really makes any difference. CFCs (and OO in general, really) are about maintenance, and there are ways you should use them and ways you shouldn't. Not knowing those rules, or worse knowing them and deliberately refusing to use them, and then presenting yourself as someone with something worthwhile to say on the subject is just plain dishonest. It's been years since I've worked on an application that was written without CFCs, and even the ones that were poorly done performed adequately. The ones that were written with CFC best practices in mind were actually extremely performant.

In other words, there's no reason for anyone's employer to refuse to use them due to performance or any other reasons but ignorance, poor design and (worst of all) hyperbole. It's no different than knowing you should be using arrays instead of lists, or that structures are passed by reference and arrays by value. Go ahead, it's OK. Use CFCs in your applications... just do it intelligently, keeping in mind what works and (most important) what doesn't. And use ColdFusion's built-in data structures to their maximum advantage: structures, queries, arrays, oh my! Use the scopes, too: server (far too often overlooked), application, session, request, variables, this, super, caller, etc. The list goes on and on.

Programming is a craft. Craft your applications wisely and you'll never go wrong (unless you're looking to trash-talk something using bad science and worse code).

Laterz!