Can Someone Change My Mind About .NET?

[Mike P.]

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]]

Mike P. <an*******@disc ussions.microso ft.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Mike P. <an*******@disc ussions.microso ft.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike P.]

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

[Mike P.]

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]]

Mike P. <an*******@disc ussions.microso ft.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Mike P. <an*******@disc ussions.microso ft.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

> 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 .NETapplications 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.

> 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 .NETapplications 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]]

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

"Mike P." <an*******@disc ussions.microso ft.com> wrote in message
news:7D******** *************** ***********@mic rosoft.com...

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.