Thanks!

Just for a take-away, I have two questions (apologies if it is an improper place to ask):

Length caching before for loop is a noticeable practice (perhaps for micro-optimization of IL or some devs have this habit as some sort of good practice). Does that mean from JIT's perspective, not doing such optimization in user code is more profitable because it hinders JITs ability to perform range check elimination optimization? Is it not feasible for JIT to detect the collection length, perhaps only to the extent when it is defined/cached explicitly in the local scope of method?

For instance, recently this PR has brought similar caching of length for performance optimization: dotnet/corefxlab#1113.

Does that mean from JIT's perspective, not doing such optimization in user code is more profitable

Correct - for loops over arrays. Caching length may help slightly for loops over collections, but it is not 100% rule. You need to measure the concrete piece code to get the ultimate answer.

Is it not feasible for JIT to detect the collection length, perhaps only to the extent when it is defined/cached explicitly in the local scope of method

It is possible, but the current .NET JITs do not have this optimization.

In general, explicit caching is typically not worth it for state that is known to be immutable to the JIT. It is typically worth it for potentially mutable state, e.g.:

void MyMethod()
{
    // The JIT is unlikely to see that _buffer is not changing between loop iterations, so it 
    // will fetch _buffer.Length from memory in each loop iteration
    for (int i = 0; i < _buffer.Length; i++)
         DoStuff(_buffer[i]);
}

vs.

void MyMethod()
{
    // It is easy for JIT to see that buffer is not changing between loop iterations because
    // of buffer is cached in a local. The JIT will likely cache buffer.Length in a register, not fetch
    // it every iteration, and also eliminate bounds check for buffer[i]
    var buffer = _buffer; 
    for (int i = 0; i < buffer.Length; i++)
         DoStuff(buffer[i]);
}

For instance, recently this PR has brought similar caching of length for performance optimization: dotnet/corefxlab#1113.

FWIW, the corefxlab change adds hoisting for iteration over Span and ReadOnlySpan (not array types). It's likely that JIT doesn't do range check optimization for those anyway (or at least not on all runtimes) and that's why it helps perf.

RyuJIT has several deficiencies wrt. Span codegen right now. The missing range check optimization is one of them. They will get fixed before Span<T> ships - folks are working on it.