¿Por qué este truco de optimización de Lua mejoraría el rendimiento?

Estoy mirando undocumento que describe varias técnicas para mejorar el rendimiento de Lua código de script, y estoy sorprendido de que se requieran tales trucos. (Aunque estoy citando a Lua, he visto hacks similares en Javascript).

¿Por qué se requeriría esta optimización?

Por ejemplo, el código

for i = 1, 1000000 do 
   local x = math.sin(i) 
end

funciona 30% más lento que este:

local sin = math.sin 
for i = 1, 1000000 do
    local x = sin(i) 
end

Están volviendo a declararsin funcionar localmente.

¿Por qué sería útil esto? Es el trabajo del compilador hacer eso de todos modos. ¿Por qué el programador tiene que hacer el trabajo del compilador?

He visto cosas similares en Javascript; y obviamente debe haber unmuy buena razón por la cual el compilador de interpretación no está haciendo su trabajo. ¿Qué es?

Lo veo repetidamente en el entorno de Lua en el que estoy jugando; personas redeclarando variables como locales:

local strfind = strfind
local strlen = strlen
local gsub = gsub
local pairs = pairs
local ipairs = ipairs
local type = type
local tinsert = tinsert
local tremove = tremove
local unpack = unpack
local max = max
local min = min
local floor = floor
local ceil = ceil
local loadstring = loadstring
local tostring = tostring
local setmetatable = setmetatable
local getmetatable = getmetatable
local format = format
local sin = math.sin

¿Qué está pasando aquí que la gente tiene que hacer el trabajo del compilador? ¿El compilador está confundido por cómo encontrarformat? ¿Por qué es un problema con el que un programador tiene que lidiar? ¿Por qué no se habría solucionado esto en 1993?

También parece haber tocado una paradoja lógica:

La optimización no debe hacerse sin perfilarLua no tiene capacidad para ser perfiladoLua no debe ser optimizado

Respuestas a la pregunta(6)

Su respuesta a la pregunta