Почему этот прием оптимизации Lua может улучшить производительность?
Я просматриваю документ, в котором описаны различные методы повышения производительности кода сценария Lua , и я шокирован тем, что такой потребуются уловки (хотя я цитирую Lua, я видел подобные хаки в Javascript). локальный x = math.sin (i) конец
работает на 30% медленнее, чем этот:
local sin = math.sin
для i = 1, 1000000 сделать
местный x = sin (i)
конец
Они повторно объявляют функцию sin локально.
Почему это может быть полезно? В любом случае это работа компилятора. Почему программист должен выполнять работу компилятора?
Я видел похожие вещи в Javascript; и поэтому очевидно, что должна быть очень веская причина, по которой интерпретирующий компилятор не выполняет свою работу. Что это такое?
Я неоднократно вижу это в среде Lua, с которой я возился; люди повторно объявляют переменные как локальные:
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
Что здесь происходит, что люди должны делать работу компилятора? Компилятор смущает, как найти формат ? Почему программист должен иметь дело с этой проблемой? Почему бы об этом не позаботиться в 1993 году?
Я также, кажется, натолкнулся на логический парадокс:
- Оптимизация не должна выполняться без профилирования
- Lua не может быть профилирован
- Lua не следует оптимизировать