Лидеры

Во-первых, твой тест заведомо некорректен, т.к. в первом случае при каждой итерации ты индексируешь таблицу (причём индексация - это довольно жирная операция), а во втором тело цикла попросту пустое. Уверен, что JIT-компилятор скипает цикл во втором случае, пытаясь оптимизировать код: Во-вторых, тема твоего поста и моя рекомендация по ipairs относится к опенкомпам, где по дефолту не поддерживается JIT-компиляция. Зачем прилагать бенчмарк на GMod/LuaJIT вместо бенчмарка на опенкомпах - мне не ясно В-третьих, у тебя используется GMod'овский таймер вместо нативного os.clock, который, напомню, и следует использовать для бенчмарка алгоритмов согласно Lua wiki Поэтому если адаптировать твой код под чистый луа, то результат будет диаметрально противоположным: local function Benchmark(uid, func, count, onfinish) local time = os.clock() for i = 1, count do func() end print(uid, os.clock() - time) if onfinish then onfinish() end end ....................... Bench() :Add("for i = 1, #tbl do", function() for i = 1, #tbl do local var = tbl[i] end end) :Add("for i, v in ipairs(tbl) do", function() for i, v in ipairs(tbl) do local var = v end end) :Start(10000000) -- 10 000 000 Ой, что же это? Медленнее в 2.7 раза? Ой-ой-ой

Начнём с того, что изначальный метод сортировки невалиден для table.sort, т.к. не учитывал все возможные варианты напрямую. Да, нативный sort в этом плане слегка туповат: Также рискну предположить, что вывод игроков на экран был хаотичным из-за использования for k, v in pairs вместо for i = 1, #array (который, к слову, еще и быстрее). Поэтому вот: local members = { { name = "Vasya", online = false, playtime = 10, offline_time = 2 }, { name = "Petya", online = true, playtime = 14, offline_time = 2 }, { name = "Sanya", online = true, playtime = 15, offline_time = 2 }, { name = "Igor", online = false, playtime = 1, offline_time = 3 }, { name = "Dima", online = false, playtime = 1, offline_time = 8 }, } table.sort(members, function(ply1, ply2) if ply1.online and ply2.online then return ply1.playtime > ply2.playtime elseif ply1.online and not ply2.online then return true elseif not ply1.online and ply2.online then return false else return ply1.offline_time < ply2.offline_time end end) for i = 1, #members do print(members[i].name) end Результат:

Я говорил именно про объявление локальной переменной внутри цикла, это чисто косметический эффект. Если мы хотим избавиться от индексирования таблицы, переменная создаётся в любом случае – явным образом или нет. Да, я понял. Мне показался слишком категоричным призыв отказаться от использования итератора ipairs. Но сейчас твоя позиция мне полностью понятна.

Не всё так плохо. Конечно, в синтетических тестах с пустым циклом разница получается значительная. В реальных же циклах разница не столь велика, потому что вклад ipairs в общую нагрузку снижается на фоне вычислений внутри цикла. А циклы-то обычно не пустые. При этом использование ipairs позволяет писать более читаемый код, позволяя отказаться как от использования индексов, так и от объявления локальной переменной внутри цикла. Ценой такого решения будет снижение быстродействия, но оно не всегда критично, а читаемость кода может оказаться важнее. Как найти оптимум, это отдельный и сложный вопрос. Пожалуй, хорошей привычкой будет писать обычные циклы for i=1,#tbl, и если код кажется трудно читаемым, хорошенько подумав о последствиях, применять for i,v in ipairs(tbl).

Тут не в функциях и точности проблемы, если захотеть, код можно секундомером отпрофилировать, но тут потребуется много повторений, статистическое профилирование.