Can Someone Change My Mind About .NET?

[Guest]

Hello

I come from the world of C++ programming, and I'm used to writing programs that are actually executed by the CPU, and that run with some semblance of performance. I have taken the time to explore this .NET thing, and found that not only do .NET applications run extremely s-l-o-w-l-y, but the various .NET languages amount to nothing more than interpreted script languages. It is the common language run-time that actually executes your implementation

I deeply resent this move toward "managed" code, and I'm disappointed that the new Avalon user interface system in Longhorn will use only .NET facilities. Is this an indication that subsequent versions of Windows will allow ONLY interpreted applications

Does anyone else share my feelings about this situation? Can anyone put forth some reason that I should feel better about embracing .NET, when it is so alien to me

Sincerely
Mike

 

[Jon Skeet [C# MVP]]

I come from the world of C++ programming, and I'm used to writing
programs that are actually executed by the CPU, and that run with
some semblance of performance. I have taken the time to explore this
.NET thing, and found that not only do .NET applications run
extremely s-l-o-w-l-y, but the various .NET languages amount to
nothing more than interpreted script languages. It is the common
language run-time that actually executes your implementation.

1) They're not interpreted. They're JIT-compiled. This is a huge
difference.
2) They don't run extremely slowly. What makes you think they do?
Certainly Windows Forms take a while to start up, and the
performance of those isn't as good as it could be - but that's
not true of the whole of .NET. What in particular are you finding
is running very slowly?

I deeply resent this move toward "managed" code, and I'm disappointed
that the new Avalon user interface system in Longhorn will use only
.NET facilities. Is this an indication that subsequent versions of
Windows will allow ONLY interpreted applications?

Certainliy not, as .NET isn't interpreted to start with.

Does anyone else share my feelings about this situation? Can anyone
put forth some reason that I should feel better about embracing .NET,
when it is so alien to me?

My guess is that you're trying to write .NET code as if it were normal
C++, rather than embracing .NET idioms. Writing code as if it were for
another platform is always going to give you nasty problems such as
performance and reliability.

 

[Guest]

Jon

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote an HTTP proxy server in Visual Basic .NET. Then I wrote an identical program in MFC. The MFC program ran many times faster. When I tested them both with Internet Explorer as the client, I saw no noticeable change in IE's performance when using the MFC proxy, while there was a serious degredation in performance with the .NET proxy

And what about the fact that you can view the code for any program just by using the disassembler utility? Am I forced to buy a multi-thousand dollar obfuscator package if I want to make a commercial app

Thank you

 

[Jon Skeet [C# MVP]]

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote
an HTTP proxy server in Visual Basic .NET. Then I wrote an identical
program in MFC. The MFC program ran many times faster. When I tested
them both with Internet Explorer as the client, I saw no noticeable
change in IE's performance when using the MFC proxy, while there was
a serious degredation in performance with the .NET proxy.

Without seeing your code, I can't say what's wrong - but chances are
it's in your code rather than in .NET itself. One thing to check to
start with - do you have Option Strict On at the top of all your code?
If not, some or all method calls will be performed with reflection,
which *is* horribly slow - and unnecessary.

It shouldn't come as a surprise though - you can't expect to
immediately write the same quality of code on a new platform as on one
you're intimately familiar with. It takes a little while to get back up
to speed. That's not a reflection of the platform itself, however.

If this proxy is small enough to post, we could see if we can see
what's wrong. I may well not be able to contribute very much myself,
being a C# programmer rather than a VB.NET programmer. I would be able
to spot *some* potential flaws, but not all. Fortunately, there are
plenty of very competent VB.NET users in this newsgroup who could help,
I'm sure.

And what about the fact that you can view the code for any program
just by using the disassembler utility? Am I forced to buy a
multi-thousand dollar obfuscator package if I want to make a
commercial app?

See http://www.pobox.com/~skeet/csharp/faq/#obfuscation for reasons why
I think obfuscation is sufficient. There are already free obfuscators
around (I believe) and my guess is that more and more of them will
spring up, and get better and better - this is what has happened in the
Java space, certainly.

 

[William Stacey [MVP]]

If possible, post your core network loop. I have not seen perf issues with
the network classes. Naturally, it will probably be a little slower then
calling win32 and winsock directly, but should not get the results you
describe.

--
William Stacey, MVP

Jon,

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote

an HTTP proxy server in Visual Basic .NET. Then I wrote an identical
program in MFC. The MFC program ran many times faster. When I tested them
both with Internet Explorer as the client, I saw no noticeable change in
IE's performance when using the MFC proxy, while there was a serious
degredation in performance with the .NET proxy.

And what about the fact that you can view the code for any program

just by using the disassembler utility? Am I forced to buy a multi-thousand
dollar obfuscator package if I want to make a commercial app?

 

[Guest]

I come from the world of C++ programming, and I'm used to writing programs
that

are actually executed by the CPU, and that run with some semblance of performance.
I have taken the time to explore this .NET thing, and found that not only do .NET
applications run extremely s-l-o-w-l-y, but the various .NET languages amount to nothing
more than interpreted script languages. It is the common language

run-time that actually executes your implementation.Tests with C# here suggests that we have almost the same speed of our MFC
programs.
The JIT compiler needs time to compile the interediate language into native
cpu code, and that explains why the .NET program starts up slower, but if
you create the program with .NET design phylisophy and not MFC like
phylisophy, then it should reach the same speeds.

I deeply resent this move toward "managed" code, and I'm disappointed that the new Avalon user
interface system in Longhorn will use only .NET facilities. Is this an indication that subsequent
versions of Windows will allow ONLY interpreted applications?

The biggest advantage if .NET is that it will improve security issuses since
the security is integrated into the code.
An OS based on .NET code will be far less vunerable for the current types of
worms and virusses. And I think the rest of the world would prefer an little
bit more secure windows that crashes less than a incredible fast computer.

Also note that, .NET programs will run faster compared to conventional
executable in the future since the Windows core is beeing replaced by pure
..NET technology.
It is the transition between managed and unmanaged that takes lots of time.
So it explains why .NET programs now are still a little bit slower since the
Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.

Does anyone else share my feelings about this situation? Can anyone put

forth some reason that I should feel better about

embracing .NET, when it is so alien to me?

I understand the you completely that itis very confusing learning to program
in a .NET way, but you have to trust all the people here that it is the way
to go for future operating systems and programming languages. But it has a
steep learning curve as the technology matures.

 

[William Stacey [MVP]]

It is the transition between managed and unmanaged that takes lots of
time.

So it explains why .NET programs now are still a little bit slower since the
Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.

That would be cool if that was the case. However I don't think that is so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api, why
would it be any faster then a comparable method in native win32? Maybe the
same, I don't see how faster. That would be nice however if wrong.

 

[Willy Denoyette [MVP]]

No, the windows core in LH is unmanaged Win32/64, and is here to stay for a
long time.

Willy.

 

[Guest]

Windows core is still unmanaged and .NET prigrams must go through that

That would be cool if that was the case. However I don't think that is so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api, why
would it be any faster then a comparable method in native win32? Maybe the
same, I don't see how faster. That would be nice however if wrong.

Simple, more an more Win32 API is beeing replaced by .NET variants.
That means that .NET programs have less and less transitions from managed to
unmanaged to do.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.

..NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because of
the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

Conventional executables are static in nature. all methods and functions are
laid out in a certain memory order at the moment you compiled and linked.
..NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a
different memory block so the the most used functions are grouped together
in a small memory address space, ready to be cached more often. Also .NET
programs written in pure OOP way is now far more performant compare to the
OOP version of a C++ unmanaged. because it does not need to delete small
memory memory bloks every time stalling then program. .NET starts deleting
the memory when it either needs memory, or if it can find some time to start
cleaning up.

Just be aware! .NET is NOT an interpreter, It compiles the complete code to
pure win32 code but optimized for your processor. When JIT matures, it ill
become even better optimizer.

Another thing that must be taken into mind, is the fact that .NET programs
also implements security at the low level standard.
You should compare Win32 functions with also this type of level of security
build in. If I remember correctly a web page counter extension for Frontpage
97 could be misused to take over the server. A stupid prgram that only
intended to show a bitmap on screen was misused. This is why all programs
now created should have this security integrated default.Even if it is a
simple screen saver, it could be misused by a worm. (examples enough: e.g.
windows help file could be used to take over your computer) Maybe next
Solitair....

But this is my opinion? I really believe that this .NET is the way to go,
and I admit that I also fight against it to have my code work. ;-)

 

[Guest]

No, the windows core in LH is unmanaged Win32/64, and is here to stay for
a

long time.

Too bad.
But then again, converting million lines of code is not that simple to do in
a few years.

 

[Brandon Potter]

Mike,

In short, no. If you like your C++ programming, there is no Microsoft army
that is going to confiscate your workstation should you not come to the
other side. If *you* think .NET can improve the way you or your organization
works, then use .NET. With that I can offer what we have seen so far, if it
helps.

It all depends on the project. C++ is totally inappropriate for some of the
things you could do in .NET, and .NET is totally inappropriate for some
applications that you may have written in C++.

We asked the exact same questions, and are trying to work out those
solutions within our own organization; i.e., the users complain that a .NET
app is slow to start (they get confused because they don't see a window
immediately and keep clicking on the desktop icon, etc, etc.), so we build a
splash screen in C++ that gets a window up there quickly and then launches
the .NET app. However, once a .NET application is running, although it does
perform a bit slower than native Win32 apps (as it should!), we have seen
firsthand how the advancements in code security and ease of domain
administration are a step in the right direction that the entire industry
needs right now. And as always, in the parallel industry of construction, if
I could build a house with only one tool, I would; but unfortunately
sometimes I need a wrench and sometimes I need a screwdriver to accomplish
the task.

The only other reason we use .NET is summed up in one of Microsoft's banner
ads from some time ago: "Why would you start from scratch, when you can
start from almost done?" -- We find something new every day that MS has
included in the framework that we had previously written our own libraries
for in C++, and the fact that we don't have to spend testing time on those
components allows us to develop in 4 days what previously took us 4 weeks.
It really takes care of the rudimentary processes / "management" while at
the same time gives us the ability to dive right into the Win32 API should
we need it.

With that said, .NET does make you feel like less of a programmer since it
manages so much for you, hence how it resembles a scripting language.
However, my personal outlook on that is if I am in a room with a C++
programmer and we are both working on, say, a $5,000 development project,
after a week of coding, the C++ programmer will still be coding the basic
framework and window management for the application while I'm depositing a
check at the bank... so that's what it comes down to.

FWIW on our organization's side of the fence,

Brandon

Hello,

I come from the world of C++ programming, and I'm used to writing

programs that are actually executed by the CPU, and that run with some
semblance of performance. I have taken the time to explore this .NET thing,
and found that not only do .NET applications run extremely s-l-o-w-l-y, but
the various .NET languages amount to nothing more than interpreted script
languages. It is the common language run-time that actually executes your
implementation.

I deeply resent this move toward "managed" code, and I'm disappointed

that the new Avalon user interface system in Longhorn will use only .NET
facilities. Is this an indication that subsequent versions of Windows will
allow ONLY interpreted applications?

Does anyone else share my feelings about this situation? Can anyone

put forth some reason that I should feel better about embracing .NET, when
it is so alien to me?

 

[William Stacey [MVP]]

Agree mostly. Your not going to get faster then native c++ to native win32
however. That model will not go away soon. Managed c++ to managed .Net
should be ~same as Managed c# or vb to Managed .net. Unmanaged c++ to
managed will have some overhead probably on par with managed to unmanaged
pinvoke has today. Many of the .Net classes still wrap win32 calls. I
would guess that will continue with WinFX, but at a leaser percentage as
more primitives may be fully managed and exposed. However, most of the low
level primitives (i.e. mutex, IPCs, semaphore, etc) would still be wrappers
around win32. Don't get me wrong here, I have seen the light and love the
managed side. If I never see another pinvoke, I will be very happy.
Cheers!

 

[William Stacey [MVP]]

With that said, .NET does make you feel like less of a programmer since it

manages so much for you, hence how it resembles a scripting language.

I don't get the scripting language reference. c# and vb.net don't resemble
any scripting language anymore then any other language. I think your
talking more about the framework anyway then the actual language. Move to
msh, ksh, perl for scripting languages. That said, perl has a .Net language
so I guess the line can blur a bit. That makes me wonder, anyone do a ksh
package for VS yet?

 

[Willy Denoyette [MVP]]

See inline ****

Willy.

Simple, more an more Win32 API is beeing replaced by .NET variants.

**** Hmmm... which Win32 API's have been replaced sofar?
More and more win32 API's are introduced by now (see W2K3 and LH).

That means that .NET programs have less and less transitions from managed
to
unmanaged to do.

*** No that's not true, .NET is built upon Win32, somehow, it will allways
need to transition between managed and Win32 for system services.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.

*** And break alot of existing applications, do you realy think the Server
and Office folks at MS are willing:
- to pay this perf. hit?
- to compromise the reliability of their server?

.NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because
of
the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

*** Don't overestimate the power of the JITter, he's heavily constrained by
the "time to optimize", and don't overestimate the power of the newer
processor family.
Don't forget that the latest native code compilers also generate better &
faster code, and that parts of the system cannot afford the overhead of the
GC both in time and space (think about drivers and core windows component
like the memory manager, scheduller, interupt handler....). And here I'm not
gonna talk about robustness, but why do you think Yukon and .NET 2.0 are
getting delayed?

Conventional executables are static in nature. all methods and functions
are
laid out in a certain memory order at the moment you compiled and linked.
.NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a

*** "might", yes but officially anounced, no. For the moment MS has other
performance issues to solve which have much more impact than some profile
guided JITter.

 

[Cor Ligthert]

Hi Mike,

Are you sure of this what you are writting about C++, are you really putting
every pixel by pixel on the screen every time again after that you have
chosen the right color from that pixel.

And are you really adding every byte to the register, accumulate the
registers, and than put them back in a memory place or to another register.

If not than what when the Net does some more than only the things you say
you are doing now with C++.

Just my thougth

Cor

 

[Brandon Potter]

When I made that reference (and I think the reference that Mike is referring
to, although I cannot speak for him), I am referring to the general
"feeling" that you get from programming in .NET (especially VB.NET) -- Since
you start a project and it's able to run and display an interactive user
interface from the first second you use it (thank you, code generator), it's
like all you have to do is put in the functionality, which is more like a
scripting language.

I have heard this reference once before by a team of programmers that wished
to remain in C++ to retain their status of "real" programmers and would not
touch .NET. I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that
keep customers happy. I guess if you are working in a RAD environment where
you can produce results quickly and don't have to mess with the more "geeky"
side of things (establishing the Win32 While() message loop and spend hours
and hours writing the code to paint the display), then it makes you look
more like a script programmer. Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

Any philosophical thoughts on "real" vs. "fake" programmer psychology?

Brandon

 

[Jon Skeet [C# MVP]]

When I made that reference (and I think the reference that Mike is referring
to, although I cannot speak for him), I am referring to the general
"feeling" that you get from programming in .NET (especially VB.NET) -- Since
you start a project and it's able to run and display an interactive user
interface from the first second you use it (thank you, code generator), it's
like all you have to do is put in the functionality, which is more like a
scripting language.

That has nothing to do with scripting - it's just being RAD-oriented.

Personally I avoid the forms designer when I can, but there we go. (I
tend to get more readable and maintainable code that way.)

I have heard this reference once before by a team of programmers that wished
to remain in C++ to retain their status of "real" programmers and would not
touch .NET.

That sounds like a silly comment to me from people who care more about
being "macho" than being productive. Why spend time thinking about
problems which have already been solved when you can be tackling new
problems inherent in whatever application you're trying to write?

I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that
keep customers happy.

Exactly - and as long as you enjoy your job, of course.

I guess if you are working in a RAD environment where
you can produce results quickly and don't have to mess with the more "geeky"
side of things (establishing the Win32 While() message loop and spend hours
and hours writing the code to paint the display), then it makes you look
more like a script programmer.

I don't think so - but then maybe I don't have the pejorative idea of a
script programmer that your colleagues do. There are plenty of times
when scripting is the best solution to a problem, but that doesn't make
it any less "real" programming, IMO. To me, a *good* programmer knows
to use the best tool for the job. There are still good reasons to use
native code rather than managed code in some cases, but "looking cool
as a programmer" is never one of them.

Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

Any philosophical thoughts on "real" vs. "fake" programmer psychology?

Try getting them to explain how they tackle all interntationalisation
problems (including surrogates etc), their multithreading strategies
etc. There's still plenty to think about in .NET.

 

[William Stacey [MVP]]

I have heard this reference once before by a team of programmers that
wished

to remain in C++ to retain their status of "real" programmers and would not
touch .NET.

As Don Box once said; "..time will take care of these people because they

I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that
keep customers happy. I guess if you are working in a RAD environment where
you can produce results quickly and don't have to mess with the more "geeky"
side of things (establishing the Win32 While() message loop and spend hours
and hours writing the code to paint the display), then it makes you look
more like a script programmer. Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

I guess you can argue either way. However, the same people said the same
things when moving from assembler and c to c++. I guess this will always
be. We love what we know and resist change at times. That said, I think
they hit a sweet spot with c# on form and function. You can almost go as
close to metal as you want to get.

 

[Cor Ligthert]

Hi William,

I don't get the scripting language reference.

C++ is too a kind of scripting language. It has not that true connection to
the computer as assembler, with which you can direct translate every
instruction in a equivalent machine code.

It is just the point of view that you use.

)))

Cor

 

[Guest]

In short, no. If you like your C++ programming, there is no Microsoft army

that is going to confiscate your workstation should you not come to the
other side. If *you* think .NET can improve the way you or your organization
works, then use .NET. With that I can offer what we have seen so far, if it
helps.

Agree.
I have started some smaller .NET projects because I can create these same
programs 7 times faster with far better user functionality including dragn
and drop, colors, tooltips,... compared to the older C++ technology using
MFC. Starting up is slower, but I do not see any noticable performance
problems. But that is because I also use unmanaged C++ functionality mixed
for none user interface stuff.

The biggest resistance I get is from people that are totally new to .NET and
have to install the .NET framework and somehow trust my strong name when
they want to use the program from the network.

With that said, .NET does make you feel like less of a programmer since it
manages so much for you, hence how it resembles a scripting language.
However, my personal outlook on that is if I am in a room with a C++
programmer and we are both working on, say, a $5,000 development project,
after a week of coding, the C++ programmer will still be coding the basic
framework and window management for the application while I'm depositing a
check at the bank... so that's what it comes down to.

I don't feel less programmer.
Now I can concentrate on important stuff and create new technology instead
of fiddeling with reading a value from a combo box.