¿Qué hace que esta función funcione mucho más lento?

Estás malinterpretando la pila.

Mientras que la pila "real" de hecho solo tiene las operaciones Push y Pop, esto realmente no se aplica al tipo de pila utilizada para la ejecución. Además de Push y Pop, también puede acceder a cualquier variable al azar, siempre y cuando tenga su dirección. Esto significa que el orden de los locales no importa, incluso si el compilador no lo reordena por usted. En pseudo-asamblea, usted parece pensar que

var x = 1;
var y = 2;

x = x + 1;
y = y + 1;

Se traduce en algo como

push 1 ; x
push 2 ; y

; get y and save it
pop tmp
; get x and put it in the accumulator
pop a
; add 1 to the accumulator
add a, 1
; store the accumulator back in x
push a
; restore y
push tmp
; ... and add 1 to y

En verdad, el código real es más como esto:

push 1 ; x
push 2 ; y

add [bp], 1
add [bp+4], 1

Si la pila de subprocesos realmente fuera una pila real y estricta, esto sería imposible, verdad. En ese caso, el orden de las operaciones y lugareños importa mucho más que ahora. En su lugar, al permitir el acceso aleatorio a los valores en la pila, se ahorra mucho trabajo tanto para los compiladores como para la CPU.

Para responder a su pregunta real, estoy sospechando que ninguna de las funciones realmente hace nada. Sólo eres siempre modificando locales, y sus funciones no devuelven nada - es perfectamente legal que el compilador elimine por completo los cuerpos de las funciones, y posiblemente incluso las llamadas a las funciones. Si eso es así, cualquier diferencia de rendimiento que esté observando es probablemente solo un artefacto de medición, o algo relacionado con los costos inherentes de llamar a una función / iteración.

Incrustar la función en la función de prueba hace que se ejecute siempre al mismo tiempo.
¿Es posible que haya una optimización que alinee el parámetro de función si siempre es la misma función?

Sí, esto parece ser exactamente lo que estás observando. Como ya mencionó @Luaan, el compilador probablemente elimina los cuerpos de sus funciones straight y inverse de todos modos porque no están teniendo ningún efecto secundario, sino que solo manipulan algunas funciones locales variable.

Cuando se llama a test(…, 100000) por primera vez, el compilador optimizador se da cuenta después de algunas iteraciones que el fn() que se llama es siempre el mismo, y lo hace en línea, evitando la costosa llamada a la función. Todo lo que hace ahora es 10 millones de veces decrementar una variable y probarla contra 0.

Pero cuando estás llamando a test con un fn diferente entonces, tiene que des-optimizar. Más tarde puede hacer algunas otras optimizaciones de nuevo, pero ahora sabiendo que hay dos funciones diferentes que se llamarán ya no pueden insertarlas.

Dado que lo único que realmente estás midiendo es la llamada a la función, eso conduce a las graves diferencias en tus resultados.

Un experimento para ver si las variables locales en las funciones se almacenan en una pila

Con respecto a su pregunta real, no, las variables individuales no se almacenan en una pila ( stack machine), sino en registros ( register machine). No importa en qué orden se declaran o se utilizan en su función.

Sin embargo, se almacenan en la pila, como parte de los llamados "marcos de pila". Tendrá un fotograma por llamada a función, almacenando las variables de su contexto de ejecución. En su caso, la pila podría verse así:

[straight: a, b, c, d, e]
[test: fn, times, i, t]
…