Visual Studio 6 and Visual Studio .net
Quote:
> sorry for squating but i would also like to get some second hand info
> (vb.net intermediate code, performance issues, msdn - in fact a quick net
> vs. 6 would be much appreciated)
Performance varies depending on what your discussing. For example - GUI
performance is slower. On a new box you probably won't notice to much of a
difference. On my PII 233 with 128 MB of RAM, the difference was
noticeable, but acceptable. On my AMD XP 1800+ - well except for a slightly
slower startup - you can't even tell the difference. My PIII 500 is
somewhere in between.
If your talking about actual code performance here is what I tested - I
don't have any number's handy, so you might want to do your own benchmarks:
1. Object creation - much faster since there is no call to AddRef. This is
only really noticeable though when creating large numbers of objects.
2. Integer math - this one varied, most of the time it was as fast or
faster.
3. Floating point operations - dog slow. The VB.NET compiler emits some
pretty funky IL for FP. If you have to do a lot of FP, your best bet is to
put in a C# class which doesn't have this problem and in fact, I believe is
as fast or slightly faster than VB6 in this area.
To be honest, on a fast box with lots of RAM VB.NET apps perform very well.
The biggest bottle neck with .NET apps in general is the JIT compiler.
Since every method is compiled to native code as they are called - it makes
your initial call slightly slower, but only the first time. The difference
should narrow over time as 1. the VB.NET compiler is optimized to generate
more efficient IL and 2. the JIT'er is optimized to generate more efficient
native code.
The biggest factor in VB.NET performance is the amount of memory. The more
the better. That's because of the size of the runtime. I have read, though
I haven't actually checked it out, that the memory footprint of a VB.NET
HelloWorld program is about 13/14 MB's. I know that sounds bad, but it
isn't as bad as it sounds. The reason is that once the runtime is loaded
(that's the majority of the 13/14 MB's) most of that is shared with any
other .NET applications that are started. This means that the memory usage
doesn't go up dramatically as you start more apps. The overall total usage
only goes up by a small amount. That's also why you can start a .NET app
and see a slight pause - close it and restart it and it will start almost
immediately. Once the runtime is loaded, it is cached so warm startups are
much faster.
HTH,
Tom Shelton
