- I’ve looked at the .NET code that runs the warehouse shipping system. It’s serious ten-foot-pole territory.
Model-Glue: Unity (and more to the point, Reactor) really does speed up quite a bit when you turn off debugging. From that whole furlongs-per-fortnight measurement that I gave yesterday to something actually tolerable to develop with. The development server at work is a Dual-CPU with 3GHz Dual-Core Intel chips (thus essentially 4 processors for 12GHz, sweet!) with 4GB of RAM, a well-indexed SQL Server 2000 database, Apache2.0, and CFMX7.0.2 on wicked-fast SCSI RAID5 drives. The existing apps on the server are fast to the point that certain coworkers are jealous of how fast my apps perform compared to their COTS .NET apps. But as I mentioned, my fresh install of MG:U/Reactor was heinously slow. The MG:U sample apps with Reactor were clocking in at 45 seconds per page, while the ones without Reactor were still in the 5-15 seconds range. Yeah. Unusably slow. Spectra slow. So, out of curiosity, last night I wiped away all of my development environment at home and started from scratch. It’s just a 1.5GHz AthlonXP with 1GB of RAM, and now a completely fresh install of CFMX7, Apache2, MySQL5, and MG:U. I dropped the sample apps in the web root and started to poke around. In the words of Keanu: Whoa. I’m not going to say it was instantaneous, but pages were coming back in under 2 seconds. I copied-and-pasted my way to a new scaffolding app with a few simple tables, and even those pages came back in under 2 seconds. All of this without putting MG:U or Reactor into production mode. So, even on a system that is in theory an order of magnitude slower than the Formula One development server at work, pages were still coming back an order of magnitude faster! Being the good believer in the Scientific Method that I am, I went into the CF Admin, turned on debugging, and reloaded the app. Wait. Wait. There we go. Pages were now clocking in at roughly 30 seconds. Again, an order of magnitude slower. Turn it off. Back to zippy-speedy. So while I am suitably impressed with how much this makes a difference, I am now left with a dilemma: debugging information is extremely useful, and I don’t necessarily want to litter my code with tags (how barbaric!), so what’s the right way to develop MG:U apps? I don’t know yet. I’ll have to futz around and see if I can strike a compromise.