@Red :)
you are ignoring something which should be obvious to you... you are thinking back to a time when you compiled your humongous app into a single binary, and all of it was run at one time... the worm has turned... the new order is something entirely different...
faster, slower, compiler, interpreter, they all take on totally different meanings in the world of .net...
No I've actually done a fair amount of reading and looking into the clr and managed performance. I'm not a guru, but I'm not out of line here either :)
http://builder.com.com/5100-6373-1027686.html
from the article..
thats just the first article I've dug up right now, but there is other similiar ones out there if you look. Ive seen them. I'd assume nop's should be easy for the jit to optimize away.. but this article points out that an extra local is created.
Thats also apparently referring to the vbc thats in the 1.1 framework. It may be improved with 2.0...just to restate my original opinion again -- I doubt these differences between csc and vbc are worth even considering( but they ARE there ).
The microsoft just-in-time compiler is quite good, but it can only do so much optimizing-- it has to be done relatively quick. Its a very limited time frame to work in. Plopping in extraeneous instructions doesnt strike me as being beneficial for performance..
Like I've also pointed out, there are situations where you can get better performance with pointers. VB.Net cant use pointers, but c# can.
you are ignoring something which should be obvious to you... you are thinking back to a time when you compiled your humongous app into a single binary, and all of it was run at one time... the worm has turned... the new order is something entirely different...
faster, slower, compiler, interpreter, they all take on totally different meanings in the world of .net...
No I've actually done a fair amount of reading and looking into the clr and managed performance. I'm not a guru, but I'm not out of line here either :)
could you confirm that with a brief example, or article from an acknowledged source... i'm not disputing this, it does seem logical, but i'd like to know this for sure...
http://builder.com.com/5100-6373-1027686.html
from the article..
Five of the extra opcodes generated by the VB.NET compiler are nop, which, according to Microsoft's current documentation, stands for "No Operation" or "pass."
· The VB.NET IL declares an extra local variable of type int32 in the .locals section. This local variable is apparently used to cache a copy of the IndentedWriter.myIndent field for use in the for loop (line IL_002b). The C# IL, on the other hand, refers to the class field directly in line IL_0021).
· The VB.NET IL uses six opcodes (IL_0000 to IL_000e) to create its StringBuilder object, while the C#-generated IL uses only five (IL_0000 to IL_000d). One of the VB.NET opcodes used here is a nop.
· Both for loops are implemented in 13 opcodes (lines IL_001a through IL_002c for VB.NET and lines IL_0010 to IL_0026 for C#). Interestingly though, one of the opcodes in the VB.NET for loop is a nop.
· The VB.NET IL declares an extra local variable of type int32 in the .locals section. This local variable is apparently used to cache a copy of the IndentedWriter.myIndent field for use in the for loop (line IL_002b). The C# IL, on the other hand, refers to the class field directly in line IL_0021).
· The VB.NET IL uses six opcodes (IL_0000 to IL_000e) to create its StringBuilder object, while the C#-generated IL uses only five (IL_0000 to IL_000d). One of the VB.NET opcodes used here is a nop.
· Both for loops are implemented in 13 opcodes (lines IL_001a through IL_002c for VB.NET and lines IL_0010 to IL_0026 for C#). Interestingly though, one of the opcodes in the VB.NET for loop is a nop.
thats just the first article I've dug up right now, but there is other similiar ones out there if you look. Ive seen them. I'd assume nop's should be easy for the jit to optimize away.. but this article points out that an extra local is created.
Thats also apparently referring to the vbc thats in the 1.1 framework. It may be improved with 2.0...just to restate my original opinion again -- I doubt these differences between csc and vbc are worth even considering( but they ARE there ).
The microsoft just-in-time compiler is quite good, but it can only do so much optimizing-- it has to be done relatively quick. Its a very limited time frame to work in. Plopping in extraeneous instructions doesnt strike me as being beneficial for performance..
Like I've also pointed out, there are situations where you can get better performance with pointers. VB.Net cant use pointers, but c# can.