Локализация глобальных функций не делает их значительно быстрее. Это делает их немного быстрее, потому что вам не нужно искать их в _ENV
; особенно если они в другой таблице, например _ENV.math.cos
. Для функций, которые находятся непосредственно в _ENV
, этот эффект явно меньше, и если сама функция работает очень медленно, небольшая разница в ее локализации не будет столь заметна.
На самом деле, вы никогда не должны локализовать функционирует только потому, что. Если у вас очень маленькое тело l oop с большим количеством итераций, которое вызывает очень маленькую функцию, вам следует рассмотреть возможность его локализации (и вы должны сделать это как можно ближе к l oop), но только если вы Вы уверены, что это будет иметь значение (бенчмаркинг - ваш друг).
Кажется, существует постоянный миф, что просто локализация каждой функции, которую вы собираетесь использовать, для всей библиотеки волшебным образом сделает это быстрее, что это полное заблуждение.
LuaJIT даже делает это само для большинства случаев; обнаружение повторного доступа к таблице внутри тела oop и локализация его вне l oop.
Также имейте в виду, что, хотя math.cos
никогда не следует изменять, вы можете получать доступ к функции из некоторый другой модуль, который фактически изменяется за кулисами, чтобы отразить некоторое изменение состояния в модуле. В этом случае локализация функции будет означать, что вы работаете с устаревшей функцией. Это не очень часто, но это случается.
Просто для удовольствия; попробуйте запустить это в PU C Lua и в LuaJIT:
local function bench(n, fn, ...)
local t1 = os.clock()
for i=1,n do
fn(...)
end
local t2 = os.clock()
return t2 - t1
end
local n = 1e7
print(bench(n, function() return math.cos(20) end))
print(bench(n, function() return tostring(20) end))
print(bench(n, function() return tonumber("20") end))
print("---------")
print(bench(n, math.cos, 20))
print(bench(n, tostring, 20))
print(bench(n, tonumber, "20"))