I ccomdensed all my replies into my first reply.
Nothing I said changed but I added an end all example of how CType() noticeably blows away CInt() on an Intel Dual Core machine with 3GB RAM running windows Vista.

Out of habbit since I always use Option Strict i used ToSting in the example I deleted.
I deleted it and put up a true test to confirm my words since as you pointed out ToString would tell the complier that it is infact a string being converted which would defeat my LateBinding Vs. EarlyBinding therory. Hence why you didn't see the results I expected you to see.

Patrick Cambria

Your code doesn't compile with OPTION STRICT ON.
Counter2 is never declared.

And it's not surprising that this loop is a lot faster. Because COUNTER is unchanged inside the loop, the compiler is able to HOIST that conversion *OUT* of the loop. I had already noted that in my own goof in that regard in a prior attempt.

If you make them BOTH use COUNTER for the loop as well as for the value conversion, you indeed get the same kinds of times I reported:
etc. (I bumped your loop count up to 10,000,000 so I could get reasonably lengthy times. If times are too short, interruptions by the OS--such as screen refresh and task monitor events--can distort times dramatically. You're going to get some variations no matter what, but the longer the loop time the more likely that such interruptions will be spread equally across the two tests. Yes, I know that's more important on my single processor machine than on a dual processor, but don't discount the possible effects even on a dual processor.)

Anyway, try your code again, but change BOTH loops to just use Counter (get rid of Counter2) and see essentially identical results. No fair comparing apples to oranges.

I did mention Option Strict BUT... Leaving counter2 in the example was not on purpose and when i changed it to counter the results did in fact change. In fact some of the results CType was slower. So frig it.

At this point I can only assome there are alot of changes to .NET that dont have any benifit other then microsoft needed smoething to sell.

I feel we didnt waste our time in this topic because I would have never ran the tests otherwise and I would have always believed wha I read in the book to be true.

PS the book does meantion using Option Strict Vs NOT using Option Strict when it discusses EarlyBinding Vr LateBinding but at this point im just going to agree with you that CType is not faser then CInt because I always use Option Scrict.

PS does the screen refresh during a loop with out the use of Application.DoEvents in most of my testing with loops that run a long time the app doesnt do anything but say not responding. Application.DoEvents allows for such Form Events to execute during the loop but when to use DoEvents vs when not to is a whole other thread topic.

On example would be when your loading a ton of items to a listbox with a loop. It displays the loading MUCH nicer with DoEvents as opposed to with out. But of course as you noted these evens would play a major role in speed.

> I feel we didnt waste our time in this topic because I would have never ran the tests otherwise and I would have always believed what I read in the book to be true.

YES! That was really my only purpose in all this. The authors' claims just didn't make sense to me and I want to show them to be wrong.

The give and take here has been good for me! I haven't done benchmarking to speak of in almost 10 years.

I think you are likely to find a lot more "urban legends" about VB (and C#, but especially VB) simply because a lot of people don't like it and want to see it relegated to second class citizen status.

Good luck in finding more of this kind of stuff! Make the authors eat their words!

[Having said all this, I have to also defend WROX, in general. I mistakenly purchased a series of 5 books from another company, just because they were on sale. Believe me, if I had only found minor mistakes in them, such as this one, I wouldn't have turned around and used them for starting fires!]