Actually I'm pretty confused now. Looking at the git history, it was a mutable variable in @manofstick's original implementation, but it was changed to use a ref during some unknown code review step. Maybe someone can give some insight into this?

Th F# compiler is compiled with all warnings enabled, including the one for when "let mutable" values are promoted to refs, to help make allocations pain. So a compiler warning would be triggered by your code.

@dsyme I don't see any errors from using the mutable. That said instead of using mutable is it instead preferred to do something like the following so that we only have to dereference once per function?

let value : Ref<'T> = ref (n - LanguagePrimitives.GenericOne)

let inline current () =
    let derefValue = !value
    if derefValue < n then
        notStarted ()
    elif derefValue > m then
        alreadyFinished ()
    else 
        derefValue

@forki, I didn't see any in the same file. I didn't check too hard for other files though.

These look good to me.

This doesn't actually do anything; the "let mutable ..." does just get converted into a ref field, as per @dsyme's comments.

I think where the observed speed up comes from is that in 4.4.1.x there is the "singleStepRangeEnumerator" optimization which I did a while back (which I guess I thought already existed in the 4.4.0.x codebase... Seemed like a long time ago!)

Anyway, it appears that my original gist was a bit of a red herring. I still think that seq {} blocks should drag the iteration into the state machine, rather than deferring it to the helper enumerable, but the effect of this is obviously not as bad as it had once been.

I think this PR should just be closed.

@manofstick You're right the mutable doesn't do anything in reality. The emitted IL is effectively the same. However, I think if we were to make the relevant function only dereference once per function call, we would in fact get some savings. Here's some of my results (note that the new Range is marginally slower for upperbound is 10,000 and 1,000,000, though it is within the measurement error of the old range) :

Host Process Environment Information:
BenchmarkDotNet.Core=v0.9.9.0
OS=Microsoft Windows NT 6.2.9200.0
Processor=Intel(R) Core(TM) i7-4710HQ CPU 2.50GHz, ProcessorCount=8
Frequency=2435778 ticks, Resolution=410.5464 ns, Timer=TSC
CLR=MS.NET 4.0.30319.42000, Arch=32-bit RELEASE
GC=Concurrent Workstation
JitModules=clrjit-v4.6.1586.0

Type=Range  Mode=Throughput  LaunchCount=5  
TargetCount=50  

Here is the gist for that test: https://gist.github.com/liboz/c9e529d0292f25135243721157b93fae

(...to ensure consumption of "Current", you should probably change Seq.len to something like Seq.sumBy sign.)

Anyway, no detrimental effects, and bit of a kick with x86, so why not?

❤️

(off-topic) Hey @forki, do you have like a performance comparison of the last releases of F# versus the current master? Just as a summary. It feels like a lot have been implemented lately?