i'm trying investigate whether dictionaries enum keys still generate garbage in newer versions of .net (say >= 4)
see shawn hargreaves blog post here details on why i'm fretting this... (http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx) specific know garbage on xbox / can problem.
i created little .net v4 console application comparing il generated dictionary , dicationary , noticed 'box' opcode in both sets of code confused me.
.method private hidebysig instance int32 findentry ( !tkey key ) cil managed { // method begins @ rva 0x61030 // code size 138 (0x8a) .maxstack 3 .locals init ( [0] int32, [1] int32 ) il_0000: ldarg.1 il_0001: box !tkey <----hmmmm! il_0006: brtrue.s il_000e il_0008: ldc.i4.5 il_0009: call void system.throwhelper::throwargumentnullexception(valuetype system.exceptionargument) il_000e: ldarg.0 il_000f: ldfld int32[] class system.collections.generic.dictionary`2<!tkey, !tvalue>::buckets il_0014: brfalse.s il_0088 https://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.box%28v=vs.110%29.aspx
convert value type (of type specified in valtypetoken) true object reference.
is box here not heap allocation? if not, how can tell when there's heap allocations might cause xbox struggle?(from looking @ il) depend on other context? memory profiler (clr profiler example) way tell sure?
yes box, no shouldn't matter in case - @ least, not regular .net; != null check; jit knows how recognise these value-types, , can remove check machine code.
allegedly.
to tell sure, you'd need @ post-jit machine code, not il.
it matter jit using, makes harder.
worst case: use coreclr code roll own value-type dictionary.
Comments
Post a Comment