If I run the attached testcase with Gecko profiler active, it shows 5ns or so per iteration. Without Gecko profiler active it's about 0.7ns. Here's what JIT inspector shows without the profiler active: Block #3 -> #4 -> #5 :: 9998904 hits [Label] [InterruptCheckImplicit] [OsiPoint] [CompareAndBranch:lt] cmpl %ecx, %edx jge ((571)) Block #4 -> #3 :: 9998903 hits [Label] [AddI] addl $0x1, %edx [Goto] jmp ((593)) ##link ((593)) jumps to ((593)) Here's the same thing with the profiler active: Block #3 -> #4 -> #7 :: 9998904 hits [Label] [InterruptCheckImplicit] [OsiPoint] [CompareAndBranch:lt] cmpl %ecx, %edx jge ((981)) Block #4 -> #5 :: 9998903 hits [Label] [FunctionBoundary] movabsq $0x100572040, %rbx movl 0x0(%rbx), %ebx addl $0xffffffff, %ebx cmpl $0x400, %ebx jge ((1022)) shlq $5, %rbx movabsq $0x10056a000, %r11 addq %r11, %rbx movl $0x2c, 0x18(%rbx) ##link ((1022)) jumps to ((1046)) movabsq $0x100572040, %rbx movl 0x0(%rbx), %ebx cmpl $0x400, %ebx jge ((1070)) shlq $5, %rbx movabsq $0x10056a000, %r11 addq %r11, %rbx movabsq $0x1abd1be50, %r11 movq %r11, 0x0(%rbx) movabsq $0x1379cf480, %r11 movq %r11, 0x10(%rbx) movq $0, 0x8(%rbx) movl $0xffffffff, 0x18(%rbx) ##link ((1070)) jumps to ((1129)) movabsq $0x100572040, %rbx addl $1, 0x0(%rbx) [Goto] Block #5 -> #6 :: 9998903 hits [Label] [FunctionBoundary] movabsq $0x100572040, %rbx addl $-1, 0x0(%rbx) [Goto] Block #6 -> #3 :: 9998903 hits [Label] [FunctionBoundary] movabsq $0x100572040, %rbx movl 0x0(%rbx), %ebx addl $0xffffffff, %ebx cmpl $0x400, %ebx jge ((1210)) shlq $5, %rbx movabsq $0x10056a000, %r11 addq %r11, %rbx movl $0xffffffff, 0x18(%rbx) ##link ((1210)) jumps to ((1234)) [AddI] addl $0x1, %edx [Goto] jmp ((1242)) ##link ((1242)) jumps to ((1242)) For simple enough function bodies, the instrumentation seems to dominate the actual inlined function or something. :( Not sure what we can do here...

Hmm. So MFunctionBoundary doesn't alias anything, right? But it's also not movable or CSEable... So it looks quite possible for the contents of the function, after inlining to be moved/CSEd across MFunctionBoundary?

I think this is a dupe.

See also the discussion in bug 948229.

Boris, can you re-check this and let me know if the performance has improved? I just landed 948229 so this should be fixed now. Confirmation would be good.

Yes, this seems to be fixed.