Writing plugins using .NET

[Flint]

majkinetor !

Also, I don't know why people say such things about .NET and don't complain much about Java.

Who says that people don't say such things about Java? They do say. But Java is not so extremely advertized by Sun as .NET platform - by MS. MS shouts everywhere that .NET is the best, the simpliest, the most beautiful and the most convenient platform for all the applications that can ever be created, for any purpose. Sun (about Java) - does not. Or at least, I don't hear it.

That's why many programmers don't like .NET: every programming suite should be used where and when it's applicable. Using .NET for creating huge complex program packages can be possible and even preferrable, because it will really simplify the programming process, and this will gain more advantages, than developing the same project without .NET. But using this huge, extremely slow platform to create small and fast plugins for small and fast program... I really can't call this a wise solution!

[majkinetor !]

Some interestin notes from the articles frenky supplied. I sumed it up here so you don't have to read this lengthy articles...

When MS announced that CLR would go into the OS and that in fact in Longhorn side by side execution would be not supported these were the considerations driving their decision. If you make the OS aware of the runtime it is possible to do amazing optimizations that would make CLR applications undistinguishable from unmanaged ones.

I agree with Antonio's comments. You are assuming that the current state of the CLR and .NET in general is fixed. Just because it has certain undesirable characteristics now does not mean they are set in stone for all time. There is work being done to optimize many things and I doubt you are the only one to notice that .NET uses a lot of memory currently. Also, as someone else already pointed out, managed or unmanaged if you code poorly it will be very evident to all. Managed code is not a license to ignore common practices and to stop thinking about what is happening "under the covers", in fact managed code makes it so much more important because you are able to do much more powerful things with fewer lines of code. This of course means you NEED to be aware of the cost of these things and alternatives that can make it less costly.

The lesson I learned, then, was: if you have a nice application that people wants then the hardware will catch up (sooner or later).
Even with 1.x it's well worth to run managed client apps due to inherent resistance against security attacks like buffer overrun.

The basic problem is that in CLR 1.x assemblies don't share pages across processes like regular dlls do. Microsoft knows about this, and this is remedied in 2.x. So difference will not be as dramatic anymore.

Sure, it's better than Java. But it's still miles apart from well written native code.

This also remind me of another comparasion between compiled binarys of ASM .com and .exe files plus C , Pascal and BASIC .exe files at the days of DOS. The size difference between ASM executables are, of course, very large. But if someone say that because of that we should keep away from those higher level languages, I'll say that the development complexity out weight the size and speed advantage when considering the development tool to use.

Everybody here praise C++, I would like to point out that there are programming languages faster than C++. Nevertheless the benefits introduced by the language are worth it. Nevertheless compiler writers always tend to push the limit with improved compilers. I think the same will happen with VMs.

Comparing the two Notepad purely based upon start up time is like trying to compare car performance without taking the cars off the lot.

If you load a 4Mb file into each of the Notepads, you may be surprised that the .NET version uses 1/3 the CPU time of the regular Notepad. Granted, the .NET version does use more memory, but given that software licenses are generally priced by CPU, this might not necessarily be a bad thing.

Two tweaks I would make to help the .NET performance numbers:

1) When openning the StreamReader, provide a large buffer size. This will take care of most of the I/O difference.

2) After loading the TextBox with the file contents, make a call to GC.Collect(). This will free up a lot of the extra memory the .NET verion used to load the file.

Bottom line, the programmer always needs to be aware of performance trade-offs being made. But even for a what is effectively a training excercise with little time given to tweaking the performance, at least in terms of CPU, the .NET Notepad greatly outperforms the regular Notepad.

 

I would like to comment on the use of computer languages in general. For instance, why did sane people ever use VB? The answer is, just because it was pushed and advertized by Micosoft. Delphi was far better and still is. Why do we use C#, which was developed by the originators of Delphi? Same answer. Why do we use Java? Because, "computer scientists" are in love with its complexity, just as a mechanical engineers love compex machines regardless of whether they perform better.
Personally, I think Microsoft and Intel set the world of computing back 10 years. THe Amiga operating system, although buggy, was years ahead of Microsoft. The 8088 chip was a short sighted design compared to the Motorola processors.

Raymond Chen and Rico Mariani recently did a 'dueling blogs' series where Raymond was trying to optimize the performance of an algorithm in raw Win32/C++ vs. Rico optimizing the same functionality in .Net/C#.

Check out this post in Rico's blog for the links to both sides of the conversation.

Very interesting reading.

Delphi was always the king of rapid Windows app development. And no 22mb .NET framework. Word.

Conclusion:

I just reread my comment and realized that in all projects I worked on, good programmers were more important that good tools

2 Flint

But using this huge, extremely slow platform to create small and fast plugins for small and fast program... I really can't call this a wise solution!

I agree with you. TC is basic stuff, like kernel for me. So we need the same speed/tools/ideas...

[majkinetor !]

Rico Mariani had a series recently on blogs.msdn.com wherein he compared the performance of an app written in both c# and c++.

http://blogs.msdn.com/ricom/

The results were interesting. Comparing first iterations of the two apps, the c# app far outperformed the c++ app. After several rounds of optimisation, the c# app still beat the c++ app, but not by as much.

His conclusion on memory usage:
...
Even with all these overheads we did a pretty darn good job right out of the gate. Remember we turned in a fabulous bottom line with zero effort even including the downsides mentioned above.

What can you learn from this? I think the main lesson is that you get the best "deal" from the CLR when you give it a meaty amount of work to do. For very small programs, if you don't mind a few megabytes of overhead you're fine but if you need to be tiny you'll be disappointed. For large existing programs, you'll be very sad indeed if you add managed code to your program to do just one very small thing -- it's not a good deal.

If you're introducing managed code, give us something meaty and you'll be much more pleased. Or else use the managed code at a time when space is not at a premium. The worst thing you could possibly do is add managed code to an already long startup sequence and have it do just a wee little something that's inconvenient to do in unmanaged code. Benchmarkers keep this in mind, and I've I said this before but it bears repeating: If you want to make this framework look bad, or any framework for that matter, then benchmark it doing almost nothing. You can get all the badness you like that way, but it's vacuous badness.

If you instead keep these parameters in mind and use the system thoughfully you can have great success -- often with comparative ease! Personally I think this Dictionary reader, the managed version, was a tremendous success

This is the best conclusion I found so far:

For example, I've been working on a mixed C++ and .net app, and accidentally had a leak on the C++ side, and suddenly a rarely used code-path that should have used 40-50Megs was using over 500. I had to go back and find and fix the leak, whereas in .net it would have been GC'ed. If the leak had been only an extra 20-30megs I might not have noticed and never fixed the problem at all.

"

I know in coorperate enviroments time is money and if you cost time fixing a leak, then you might get to expensive. But really, you can't be serious right? Memory leaks should be fixed. Bad code should be fixed. Almost makes me want to say MS wants .Net so that we can all put more crappy code on our systems. Who cares wether it's bad or not, atleast it won't crash your system. No really, that's why I don't install .Net, and don't run .Net stuff. .Net makes it to easy for people to write sloppy code and get away with it.

[frenky]

2majkinetor !
When comparing one language to another it's like comparing apples and pears. Both are fruits but not the same, and some of us like one over other...

[SQUIRE]

So what conclusions can we draw from all this?
[1] Badly designed and implemented code is poor code irrespective of the platform you use
[2] Some RAD environments are better than others at trapping careless mistakes at the expense of bloat
[3] .NET offers no discernible benefits over current practice if you want small, fast programs
[4] There's a memory footprint issue with .NET which MS is aware of and trying to correct
[5] .NET is work-in-progress which may (or may not) improve
[6] The likely 'winner' (for a while, at least) in the RAD stakes will be the one with the most marketing clout and ability to generate hype
[7] And the answer to the question posed by the thread starter is: don't do it for now!

It's the old dichotomy all over again: do I want to write a small, tight, elegant app and spend 2 weeks designing and debugging it, or do I give up control and use a RAD and have it done and dusted in 2 days? From a commercial point of view it's no contest - and from an intellectually-satisfying point of view, it's also no contest. That's why the open-source community was born I guess. Casual users don't really give a damn which method is used so long as it works, but I suspect most TC people do care about the nuts and bolts of the operation.

Why do we use Java? Because, "computer scientists" are in love with its complexity, just as a mechanical engineers love complex machines regardless of whether they perform better.

Couldn't have put it better myself. It's interesting to look at the bit torrent clients Azureus (written in Java) and the other contenders like BitTornado, uTorrent, etc. (written in C). The former is very pretty indeed and the others will never win a beauty contest. Performance-wise there's not a lot in it since they all spend most of their time banging TCP/IP packets about, but the Java2 platform used by Azureus has almost 4 times the memory footprint of BitTornado and is even 3 times Opera's size. Of course, memory is cheap these days but I can't help feeling a little uncomfortable at the thought. BTW, FireFox is written in C/C++, not Java.

Writing code is like writing poetry.
When you're writing code, you are focused on conciseness. Like a poet, you are thrilled when you find a single expression that covers all the nuances you're trying to convey. You are intent on writing only what is necessary, no more. Beauty is in the small.

I really like that quote which I came across in some blog! I sure hope every man and his dog won't adopt the .NET Framework wholesale because the last thing we need is yet another monopoly open to abuse. Maybe it'll follow in the footsteps of Java - a lot of sound and fury for the first few years and then become just another platform to be chosen for the right reasons.

[majkinetor !]

Amen !