How much stuff does .net do that isn't required?

Question

As the title states; how much work (as a rough percentage figure, if that's possible) does the .Net BCL do for a typical Windows application that isn't strictly required as far as Windows itself is concerned? Presumably everything that Winforms does that has an analogous functionality in MFC, the latter is the ultra-efficient implementation. Obviously the reason we use .Net is its flexibility, and it does a lot of things to make life easy for developers - after all, Winforms is a wrapper to Win32 for many basic features. I was wondering how this adds to the application overhead, and how much in principle could be pared down and still permit the application to maintain identical behaviour.

Answer 1

The question about what is required is pretty philosophical. C++ has its own overhead in comparison to the pure assembler, which in turn makes some not really needed things in comparison to the (hypothetical) specialized processor developed for running the single application.

From the other viewpoint, you shouldn't underestimate complexity, extensibility and maintainability, which can vary from one language/framework choice to another.

Another concern is feature set provided by the framework: making custom controls in pure MFC/C++ is a much more painful operation as that in .NET/WPF (imho).

The ultimate concerns in chosing the language/framwork are anyway the needed costs, time and quality of the application. All other seems to not matter much, at least in commercial software development.

Answer 2

Since .Net is an add on to Windows it's theoretically possible to re-implement it without changing Windows itself. So nothing in it is absolutely required. I suspect there's a different question behind the one you asked - care to ask that as well? :)

Answer 3

One of the aims of .NET is to provide a level of abstraction which saves a lot of the plumbing that needs to be taken into account when using lower level frameworks, e.g. MFC, to solve a given requirement. Of course, with this comes some cost. For a given problem it would usually be possible to write assembler code which has a lower resource cost than an application written in a high level language/framework. But consider the investment involved in writing the assembler code. Think of all the work that has already been done up front for you by some very clever people indeed. A good example is C# execution speed compared to C++ execution speed. The JIT compiler, which compiles IL at runtime, is an incredibly clever and complex piece of software. If you can beat it by writing low level optimisations in C++ then you probably need to be a) very clever and b) have enough time on your hands. It usually doesn't pay to take the lower level approach.

Answer 4

Well, technically, nothing in the entire graphical user display is required to perform computations on a computer at maximum efficiency, so in that regard Win32 and WinForms and MFC are 100% superfluous. ;>

MFC is "ultra efficient"? Only in the sense that it does nothing. MFC is a thin wrapper around Win32 that does very little for you compared to other application frameworks on Win32. The "ultra efficient" implementation is to do everything yourself by using the Win32 API directly. And, IMO, Win32 APIs are easier to use and understand than the MFC wrappers and macros.

There isn't really a good answer for your question because the overhead you're worried may be unnecessary is necessary for features you may or may not be using and features you are using that you may not realize require that infrastructure. Some of the most valuable infrastructure features you're discounting are productivity and ease of development.

If you consider file size as a mark of "efficiency", a .NET DLL will always be 100x to 1000x larger than a module built from hand carved asm because the .NET DLL includes the symbol information as well as the instruction logic. Yes, it's overhead, but how many man-years does it save you when you want/need to search through available types in the DLL at runtime or use some feature that depends upon that level of service? You'll never get that from ultra efficient hand carved assembly language. How about building a DLL that will run native code speed on both 32 bit systems and on 64 bit systems? Easy to do in .NET, very hard in C or assembler.

The definition of efficiency depends entirely upon what you value most. Developing in .NET is a more efficient use of my time than hand coding assembler because I can get more usable work done in the same amount of time in .NET than in assembler. Assembler and C are more efficient in terms of disk space and raw single threaded CPU performance, but disk space is cheap and single threaded can't make full use of the CPU anymore.

The cardinal rule of software development: "Fast, Cheap, Easy: Pick two."