>>>
>>>Interesting. TBH, I too expected the 'as' version to be quicker because of repeated cast in the 'is' version - but a *really* clever optimising compiler might have factored that out?
>>
>>I don't think an optimizing compiler can do that. It can take the conversion and test outside the loop of course - I have turned optimization off for the test - obviously
>
>>>Anyway, now I'm wondering how the IL offset values relate to execution time - given the total offset for 'is' is 29 and 'as' is 23 this obviously doesn't reflect the true cost when translated to machine code. I wonder how results might vary with different processors ?
>>
>>The IL offsets do not (or hardly) infuence execution time
>
>
>>As I said - the AS construct needs only one lookup in the type table(s) whereas AS needs two (IsInst + Cast)
>>
>>One ild instruction may result in many assembler instructions - eg callVirt, IsInst(ance), cast, ...
>>
>>
>>In optimizing there's something like elimination of common subexpressions - but I don't think that applies here
>>There's also dead code elimination - but not applicable here either
>
>>I do not think the optimizer can be that clever - but I may be wrong.
>
>I was working on the assumption that if you could see that a 'as' solution would work safely (and more efficiently) then there is no reason, in theory, why a compiler could not make the same decision :-}
>
>>All in all it's not the ILDasm that is optimized but a pseudo asm, that is later translated into target asm
>
>>
>> For more info - it doesn't digest easily - but it helps to sleep
>>
>>[amazon uk does not have it in stock - but you can find a TableOfContents on amazon.co.uk]
>>http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811/ref=sr_1_1?ie=UTF8&s=books&qid=1263979926&sr=8-1
>
>Not sure I want to go there :-}
>In the distant past I actually helped write a compiler (targeting a Z80 so that should give a clue as to how long ago it was). In those days the concept was manageable - these days I wouldn't have a clue :-{
>
>This might be interesting tho : http://www.amazon.com/Inside-Microsoft-Net-Il-Assembler/dp/0735615470


Well - sometimes, I read a bit in the compilers book until I sleep

I do have this one http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463/ref=pd_sim_b_2
It also helps to sleep



A long time ago - I had a customer that had ported a C program under windows 3.xxx to an mc68010 (32 bit) under unix.

His program every so often core dumped. Conclusion: we delivered computers of an 'undetermined' quality

The unix debugger was - if I recall right - adb
[I had been on a little assembler/debugger course in Maidenhead before ]

When debugging it - I could tell the programmer that he had allocated an int on an odd address boundary.
So, I made him change his alloc routine to always return an even adddress. Needless to say I had made quite an impression

Ah - the distant past - where are the days ... [ or : those were the days ]