Why is VB.NEt so slow * Rant * Maybe?

[CoderNewbie]

It seems that everything I do in .net takes so much longer to execute (not in the IDE but with a finished .exe) then it took in vb6. A simple console app takes forever to process simple things and output them to the command line. Is this just me or has anyone else noticed this? Hopefully its just me

Sorry for the rant! Just VERY VERY VERY new to .net and not sure if its worth sticking with.

Thanks for looking

[Edneeis]

Initial start up of apps is longer but that is about it that I have noticed here. Although I'm sure others will agree with you. Another thing to remember is that the first time the app is run it must be compiled by the JIT so subsquent running should be much faster. We don't see that part much as developers though since we are usually running it right after a new compile forcing it to be compiled again by the JIT. Also I should note that its not just the very first time that would be reset everytime you restart your machine and such, more like the first time in a 'session'.

[nemaroller]

There is also a .Net utility called Ngen (i think) , that precompiles the code into its native machine language. You could use that and see if it helps.

http://msdn.microsoft.com/library/de...torngenexe.asp

Be aware of these factors though (from MSDN):

The version of the .NET Framework.
If you apply a patch, QFE, or update to the .NET Framework, all native images that you have created manually using Ngen.exe become invalid. These assemblies will still run, but the runtime will not load the assembly's corresponding native image. You must manually create new native images for these assemblies.

The .NET Framework automatically creates new native images for the .NET Framework libraries that it installs.

The CPU type.
If you upgrade a computer's processor to a new processor family, all native images stored in the native image cache become invalid.

The version of the operating system.
If the version of the operating system running on a computer changes, all native images stored in the native image cache become invalid.

The exact identity of the assembly.
If you recompile an assembly, the assembly's corresponding native image becomes invalid.

The exact identity of any assemblies the assembly references.
If you recompile any of the assemblies that an assembly references, the assembly's corresponding native image becomes invalid.

Security factors.
Changing machine security policy to restrict permissions previously granted to an assembly can cause a previously compiled native image for that assembly to become invalid. Specifically, revoking any of the following permissions causes an assembly's current native image to become invalid

[<ABX]

I cant remember if compile mode affects the speed of the app or just the size but try setting the app to release mode and compiling...

[Kasracer]

It's VB.......

[/Thread]

[nemaroller]

The only (popular) language faster than Vb.net is unmanaged C++.

You may want to re-examine your code.

[PT Exorcist]

Originally posted by nemaroller
The only (popular) language faster than Vb.net is unmanaged C++.

You may want to re-examine your code.

you're wrong. there are languages like delphi that always were compiled and not interpreted

[nemaroller]

And delphi is about as popular as Robert Bertman. (cubs fan)

[PT Exorcist]

the thing is a lot of people use it

[nemaroller]

Assume for a second you disregard Delphi as popular or unpopular, what language(s) are you implying are faster than .Net JIT compiled languages?

Its not Java...its on par with C#/VB

C/C++ is the only language that you notice a significant difference.

[PT Exorcist]

asm

[nemaroller]

Let's stick to RAD languages

[hellswraith]

I agree with nemaroller, if you consider the languages that are in wide spread use today in the business environment, you will find there are very few. Sure you can go and make points for one of the 100's of languages out there, but they don't matter at all. Except in a few minor places they are used, they are wholly unpopular in business environments.

You basically move to C++ if you want speed over .Net. That is just a fact in most businesses. You won't move to Java, it is the same or slower. You can move to VB6, but in all honesty, it isn't that much faster, and isn't even close when it comes to what you can do and how fast you can do it. And last, but not least, businesses that are already using vb.net don't want to go back and develop in vb6 anymore. They see it as obsolete.

So the only option is C++ for faster windows apps. Delphi isn't as popular as some people want it to be. VB6 is way more popular and it requires a runtime. I look at delphi developers the same as I look at Mac people. They try and try to prove that their language/OS is better and faster, but never seem to get their point across to the masses.