No one can say languages are the same to me ever again!

LongRange Shooter

I just finished a grueling 15 system code review. Sheesh. But interesting of all is that there was quite a mix of VB.NET as well as C#.NET. There were two things that caught my eye in these reviews right away: 1) when the developer got a row from the database but did no casting whatsoever (to populate a string field) VB.NET compiled the code without complaint. It then resulted in IL that called GetValueFromObject that then was passed into StrObj.StringFromObject. 2) when a developer accessed a method inside a dll that was referenced but no using statement given, VB.NET compiled the code without complaint. The IL it puked out was LateBinding creation of the object and LateBindingCall into the method. ...and the reason for all of this review was to find out why the applications are running so slow. In looking at the IL from the C# code, not once did I have a cast from object or a late binding call in any of the code. Simply because C# would not allow these common faux paxs to occur. So no one could ever tell me that VB.NET generates exactly the same IL as C# does. Now----> before anyone begins the counters ---> a well written VB.NET program (I did encounter 1) will generate the same code in C# as in VB.NET. As long as the developer is not lazy, checks the object types he/she is working with, and makes certain to always add a Imports statements every time a reference is added. Also -- some of the C# code was not all that pretty and there was an extensive amount of string concatenation using "a" + "b" + ... as well as excessive object casting and creation. But that just shows a bad developer can write bad code in either language. But I now understand what one Microsoft engineer (off the record) meant when he stated that 'even a good developer can easily write bad code in VB.NET'. -- modified at 13:48 Wednesday 15th March, 2006

Christian Graus

Yes, VB.NET is weakly typed. This is one of many ways that VB.NET allows you to write bad code, in the interest of helping people write code at all :-) As your off the record source said, this means you need to know the language REALLY well to write good code with it. Christian Graus - Microsoft MVP - C++

Duncan Edwards Jones

Option Strict '--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd

Rama Krishna Vavilala

theRealCondor wrote:

find out why the applications are running so slow

Does the application runs slowly because of this late binding only? Is that the major bottleneck?

My Blog

LongRange Shooter

Nope, not just late binding, but: late binding creation late binding calls deeply nested casting from object (a maximum of 14 casts in one line of code) extensive amounts of string concatenation that really stressed GC postbacks on datagrids requiring ViewState active ..and the list goes on.

Nish Nishant

theRealCondor wrote:

The IL it puked out was LateBinding creation of the object and LateBindingCall into the method.

You mean it used Reflection? Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!

LongRange Shooter

...yes, Option Strict does a nice job. But the developer has to know it is there and then he/she has to go in and set it with each new solution. Most of these developers were either VB6 developers or COBOL coders sent in to learn a new language. So few if any knew this option existed and did not have the inquisitiveness to seek it out. And since it is off by default (a mistake on the VB teams side IMHO) it usually is overlooked until it is too late. And when you do finally turn it on, then VB has this nice way of spitting out a short list of errors and reporting: Maximum number of errors reached. At that point the error list stops as does any further compilation.

Shog9 0

Heh. A while back, we ended up using two different wrappers for MSXML in our software, one generated by the VC6 wizard, the other generated at compile-time via the #import extension. Fundamental difference? The VC6-generated wrapper did everything through IDispatch. Guess which one performed significantly better when calling setAttribute() in a tight loop... ;) Moral of the story? If you don't know what your program is really doing, you're gonna have a hard time making it do what it needs to do faster.

---- Scripts i've known... CPhog 0.9.9 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.1 - printer-friendly forums

LongRange Shooter

Well....I did not expand the logic that is inside Microsoft.VisualBasic.dll ...but it actually creates a call to LateBind(object name) and LatBindingCall(latebound object, object method name) It did not directly use Reflection. In fact within several of the functions like GetStringFromObject the Microsoft.VisualBasic.dll logic does not do a straightforward obj.ToString() call. Instead it does about a 15 statement switch statement based on the objects type. -- modified at 14:01 Wednesday 15th March, 2006

Daniel Grunwald

Nishant Sivakumar wrote:

?

Yes, if you forget to specify the type of a variable in VB, every member access on it will use Reflection.

LongRange Shooter

Yup, in total agreement here. That is why I chose to evaluate all programs by using Reflector against the IL instead of reviewing the developers' straight source. (though I reviewed that as well) I wanted to make sure I reviewed all systems based upon what is being done under the covers rather than what was visually happening.

ToddHileHoffer

Turn option strict on. If compile fails then code review = failed. If you turn option strict on then vb.net is more strict then C#. So your post is pointless. "People who never make mistakes, never do anything." My Blog -- modified at 14:13 Wednesday 15th March, 2006

Alvaro Mendez

theRealCondor wrote:

there was an extensive amount of string concatenation using "a" + "b"

There's nothing wrong with that. This code: string s = "a" + "b"; gets compiled into: string s = "ab"; and, string s = "a" + someString + "c"; gets compiled into: string s = string.Concat("a", someString, "c"); Alvaro

... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds

Christian Graus

ToddHileHoffer wrote:

So your post is pointless.

No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO. Christian Graus - Microsoft MVP - C++

Nish Nishant

Christian Graus wrote:

No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO.

The very fact that it's off by default is a pointer to the intended target audience for that compiler. Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!

LongRange Shooter

You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into. a+b+c gets compiled into exactly that, a+b+c. execution then creates a string object that represents a, creates a new object that represents a+b, creates a new object that represents a+b+c then assigns that instance to the value variable. String.Concat() is different and performs the above in a slightly more efficient fashion, but a+b+c never gets compiled into a String.Concat unless you explicitely code it that way. And you still end up with some additional objects. Now you put that into a loop that performs a+b+c 75 times and you have somewhere in the neighborhood of 250 objects flooding the gc heaps. And, I believe, that each of these objects must be Finalized() which adds further overhead to the GC operation. On the otherhand, if you perform that loop with StringBuilder and cast it to a string, then you create only 2 objects on the heap. There are 10 kinds of people in the world.
Those that read binary...
...and those who don't.

Christian Graus

Nishant Sivakumar wrote:

The very fact that it's off by default is a pointer to the intended target audience for that compiler.

Now Nish, you know there are no pointers in VB... :P Christian Graus - Microsoft MVP - C++

LongRange Shooter

LOL :laugh: There are 10 kinds of people in the world.
Those that read binary...
...and those who don't.

Jim Crafton

I think you missed something - you're referring to compile time optimizations with string literals, whereas the OP is saying that all of the string concatenation is happening at runtime, all dynamically generated, so I doubt it would be able to do this, or at least not as effectively. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!

Alvaro Mendez

theRealCondor wrote:

You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into.

:wtf: You think I'm pulling what I said out of my ass? Evidently you're the one who needs to use Reflector. C#:

public void TESTING_STRINGS()
{
string s1 = "a" + "b";
string s2 = "a" + s1 + "c";
}

IL:

.method public hidebysig instance void TESTING_STRINGS() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldstr "a"
L_000b: ldloc.0
L_000c: ldstr "c"
L_0011: call string string::Concat(string, string, string)
L_0016: stloc.1
L_0017: ret
}

Alvaro

... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds