Codito Ergo Sum

When I signed up for the Diablo III beta, I noticed they had a spot to register other products that you owned.  I popped in my Diablo II CD key and expansion key, and I noticed something amazing:  They had an OS X download for Diablo II!  I quickly jumped onto that, and download it, and whats even cooler:  You did not need a play disk in the drive to play! works on Battle.net, runs good on my MBP.  Starcraft works too, so dig out those old CD keys, and go nuts!

www.battle.net

Last week I rebuilt my work workstation (an old server actually, running 2003 Std server, dual 3.06 Xeon's, 4 gigs of ram, I love it).  Of course, that meant that Coldfusion gets re-installed.  One of the apps I am developing is a very large Model-Glue / Coldspring / Transfer ORM application that makes heavy use of objects.  There is a little script in the onAppStart method that times how long it takes for the application to fire up, and writes a log entry with that data. The first time I fired up the application after installing CF, it *really* felt like it was taking a long time, so I went to check out the log.

Application reloaded in 165.563 seconds from 127.0.0.1.

OK, yea, that took a long time.  Then I realize I hadnt updated the coldfusion JVM yet.  So I went out and grabbed the latest JDK (note, you need the JDK, not the JVM only), and installed it to the default windows location.  Since I have Coldfusion developer installed in multiserver mode, I went to e:\JRun4\bin\jvm.config, and I changed the java.home line near the top to point to my newly installed JDK location, like so:

java.home=C:/Program Files/Java/jdk1.6.0_11

Then I stopped and re-started the coldfusion services, and fired up my application again...

Application reloaded in 14.453 seconds from 127.0.0.1.

Holy smokes! What a huge difference, 151 seconds faster!  So, lets say you are reloading your application maybe 4 times an hour throughout the day to test changes. 8 hours a day (yea, right, dont I wish!), 40 hours a week, 52 weeks in a year....carry the 1.... wow, after a year of struggling along on the stock JDK with its classloader bug, you could waste 349 hours in a year JUST reloading this application.  I bet this is a worse case scenario of course, but this should illustrate why updating today is a good idea!

*edited*

Aaron Longnion has some questions regarding the status of the 'save class files' and 'trusted cache' options which may have effected this test, so I ran a more thorough test and noted times for each one. Upgrading to the latest JVM has not only been rock-solid for stability, but it has proven to be much faster for both my development and my production servers (in load testing, after tweaking garbage collection, my production cluster was able to handle a far greater traffic load with the updated JVM than without it)

There was an interesting post by John K yesterday on the Transfer-dev list, where he was asking about creating a transfer object that had no database behind it.  Basically, define the object in XML and then use the get / set methods to persist data around in a nice auto-generated cfc 9one of the things that Transfer is do good at).  There was some discussion whether Transfer would let you do this or not, so I had to give it a shot.  Turns out, you can define your object without any database and it works fine!

This started my brain going, you could define decorators against your objects, and use those to email a contact form that gets populated to your transient bean.  I think its kinda a slick way of making objects, and it would certainly be simpler to define the XML properties than creating a new cfc with get / set methods.  Anyone see any downfalls?

Oh, let me taste your tears, the tears of unfathomable sadness!

OK, this is silly...