I am a Microsoft .NET developer. As such, it was big news for me {this past week} when Microsoft announced they would drop the newest revision of Visual Studio (2012 aka 11) On Wednesday, Feb 29 2012. This going to come replete with the .NET 4.5 Framework, and the Entity Framework 5.0 built in. The beta of ASP.NET MVC 4 was released several days ago, and it is also supposed to be built into .NET 4.5 framework.
For me, the .NET 4 framework was a snoozer. The performance hit this version of the framework foisted upon us nullified any of the benefits it purportedly gave us. Nothing about .NET 4 was compelling enough to make me want to accept the big slow-down in performance . For the most part, I continued using the .NET 3.51 client framework in 64 bit mode. This was the sweet-spot for high-performance data processing in an highly-automated environment like the one I work in. A multi-threaded console application written in the .NET 3.51 framework, NGEN'ed for x64 processors, can process and transform millions of rows of financial records in very little time.
Most programmers just don't care about performance hits. We just want to use the latest thing, so we can say we are state-of-the-art. We are often content to throw away processing power for no good reason. Most programmers don't think in financial terms about their code. We are not good about evaluating the cost implications of the slow-downs we gladly accept.
Consider the following example. A Microsoft blogger recently bragged on the performance improvements Entity Framework 5.0 would bring to the table. He published performance test-data that indicated that UPON SECOND EXECUTION, EF5 would execute a transaction 400% slower than ADO.NET, whereas EF4.3 would execute it 2,300% slower than ADO.NET. On first execution, EF5 is also 2,300% slower than ADO.NET.
These findings were advertised as a magnificent 600% speed up. We were supposed to applaud. We were supposed to smile as we learned that we would get this marvelous speedup for free when we upgraded to .NET 4.5.
So, I am to applaud when I discover that my transactional operations will performance a mere 400% slower under EF5 than they would if I wrote some better code. It is better code, just to make sure you understand that. It's not worse. It's 400% better. Better is as better does.
The real take home story of this blog post is that I will cut the carrying capacity of my enterprise servers by 75% if I accept the 400% slow-down that Entity Framework brings to the table. Stated more precisely, I will need to buy 400% more servers (or virtual cloud capacity) in order to meet my needs if I fuck around with the Entity Framework. This should come at something like a 400% increase in cost right?
Let's see... that would make me a fucking stupid bastard wouldn't it? Waaahhhh...? I am a stupid goddamn bastard if I fuck around with the Entity Framework, aren't I? If I throw away 75% of my server's capacity and increase my costs 400% just so I can say I use the latest wiz-bang crap from Microsoft, I am a stupid bastard, aren't I?
There are a few non-lemmings like me around out there in the world. We have been banging on Microsoft about these logical and financial problems. When confronted with the facts found in their own publications, Microsoft ambassadors quickly fold over, admit that they have performance issues, and say that they aren't done tuning their code yet. They promise us that big performance gains are still in the offing. They are working on it.
They say we will be pleasantly surprised when we test the performance of the final goods.
What does this mean? Perhaps they can get the performance hit down to 2:1? Perhaps we will only throw away 50% of our server capacity and double our costs when the final edition is shipped? Probably too good to be true. I doubt the performance/cost picture will be that good when the final facts are published.
2012 is the year when I get serious about launching my own smart-phone web-enterprise. You know I am working on a Synastry Engine right now, and I will need web-services to deliver the info to both phone-clients, web-customers, and potential partners.
If the objective is to make money, if the objective is to make a living, if the objective is to stay alive, I will need to think in economic terms about my code. The entire structure and nature of my software project has to engineered in such a way as to maximize carrying capacity and minimize costs. When writing code, I do so according to the same motto StackOverflow.com uses: Be fast at any cost. I don't care how hard the code is to write, if it performs faster, it is better code. If it increases my carrying capacity, and reduces my costs, it is better code.
Such differentials will make the difference between life and death, if I am not doing well financially. It will also make the difference between life and death if my project takes-off, and becomes the next big thing in the web world. People don't understand the immediate survival problems over-night sensations experience when hundreds of thousands of new users begin to hit your web-apps every single day. In this situation, carrying capacity is stretched to the utter limit. You'll wish you had written leaner and meaner code if this ever happens to you.
It could make the difference between being able to self-finance and being forced to sell my asshole to investors.
Visual Studio 11 drops on Wednesday Feb 29, one day after I have surgery on my left hand. I am going to have a bit of time-off for recovery. I intend to play with this new system whilst I recover. I won't be able to write new code, but I will be able to click the mouse and recompile old-projects under the new framework. I will be able to benchmark how fast the new system works.
I suspect it will be a lot slower. I hope it will be a lot faster. I won't use it unless it is faster and more efficient. You won't get my vote unless you improve my performance/cost profile.
