[I’m moving some my more interesting old blogs from web archive to someplace they can actually be found. Keep in mind these were written a lot time ago.]
I’m going to have a little bit of fun with this one so bear with me. :)
Sometimes I talk to groups that have adopted managed code and they’ve gone a bit oopaholic. Or maybe even a lot oopaholic. (See this video if you would like to hear a little more about the perils of oopaholism). Oopaholics are often in denial. Sure their data is big but no worries, they “can handle it”, once things have matured “all will be well.” Everything is “under control.”
If you corner an oopaholic they sometimes say doozies like this one I heard not too long ago.
“The reason [edited] is so big is because of poor documentation.”
Wow that one was surprising. Big objects due to poor documentation. But fear not! Rico to the rescue! I’ve done a very careful examination of the managed subsystem and I’m now prepared to *officially* document my results. No disclaimers this time. Here it is, the unadorned truth.
In the managed world one byte still equals one byte. If you build a system that requires ten times as much managed storage per equivalent data structure compared to unmanaged code you will in fact use ten times the memory and be ten times bigger than the equivalent unmanaged system. Let the confusion end now! Managed bytes are not “90% fat free” all the bytes actually count. Really and no kidding around.
I wish I could offer you “diet bytes” but I don’t have those. Just regular bytes.
Yup the code too.
Phew. Now we can rest easy knowing that it’s fully documented. I sure feel better :) :)
Count your managed bytes just as carefully as your unmanaged bytes and you’ll be taking a good step (one of twelve?) to better performance.