Visual Studio 2012 drops on Leap-Day, Feb 29

I haven't blogged much in the past several years about my chosen profession as a software developer.  Today, I will.

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.

The Entity Framework really needs a generic table fetch method

For those of you only marginally familiar with the entity framework, the top object in the system is the DataContext object. Visual Studio will generate a sub class of the base type DataContext for you, and it does so based on your SQL database model. In the end, you get subtype filled with types that look like your SQL tables. You query from this schema. You could use Linq. You could use the fetching methods associated with Entity Framework.

So here is the rub. When you are working on a Model-View-ViewModel app, you need to write a lot of redundant boilerplate code for each one of your EF framework objects. The code is absolutely identical save for the EF framework class type. The type varies. You may need a Model class for customers class. You may need one for Institutions class. You may need one for Products class. I can go on. A close examination of all three of these model classes will indicate that they are identical, save for the type.

This is the perfect moment for the use of Generics. You should write a generic model class and pass in the type parameter. BANG! You have just created the universal model class.

Guess what? You get fucked in the ass (savagely) if you try to do this. When you attemp to write this generic model class: BANG! You run smack into one brick wall. Your DataContext cannot be type parametrized in a generic fashion. Suppose I have written the following code:

var db = new IndirectEntities(); // This is my DataContext

I cannot subsequently write the following code.

/* Psudeo code, my fucking blog engine screws with angle brackets */

var QueryResult = from r in db.Table(of Customer) select r;

Believe it or not, this will stop you cold, frustrate the hell out of you, and stymie your progress. Without the ability to fetch the table collection by generic type param, nothing follows. You cannot construct an operational generic model class without this missing feature. If the Entity Framework were at all friendly to the use of generics, it would be totally possible, and highly effective. Unfortunately, the EF basta... errr... gentlemen did not perceive any use in supporting generics.

I have been probing Google all day looking for a solution. It would appear that Microsoft left this function out of the entity framework. Perhaps it seemed a trifle too dynamic for their tastes. Many people seem to have busted their skulls on this issue. So far, no solution. Some have suggested using nHibernate, although I am not sure that is a solution.

So, here I sit, redundantly cranking out the the same fucking boilerplate code over and over again, when one generic class would have killed the bitch outright. Of course, this is where a code generator would be good, but I should not have the need to set one up. A generic class should have shot this problem down.

Double dumb ass on the Entity Framework team. You just weren't thinking there were yah?