>>>>
>>>>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

I saw that one listed but didn't notice that it's the same author (Serge Lidin) who wrote the MS book (and the assembler itself).
Might get that instead - I tend (with exceptions) to like the Apress format......

>
>
>
>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 ]