Почему lua?

Это принимается, поправлю, но 36 или 25 таки не на порядок

Ну там массивы вообще вроде тупые в луа, но других-то там нет, поэтому приходится использовать, что есть…

Ну покажи мне другой, более умный, где будет LuaJIT == V8 :)

Ну, кстати, я у себя проверил - на Lua 5.4 разницы практически нет - с #arr 18 сек, со счётчиком 17.5 сек.

А вот на LuaJIT разница есть и эпичная - без счётчика 25 сек, а со счётчиком 3.5 сек.

Короче говоря, в LuaJIT #arr эпично тормозит.

Как я понимаю - это плата за многомерность. В тех СУБД, с которыми я работал такой же эффект, когда хочешь посчитать количество значений поля. Грубо говоря COUNT(Record<2.M>) он как бы есть, но лучше его не использовать вот прям так, в лоб, на каждый чих.

Ваш вариант кода с JS я тоже погонял. Скорость, конечно, впечатляет. Но там по памяти получается в 3 раза больше, чем ваш код с lua.
Чудес всё равно не бывает. Или память, или ЦПУ.

-    local s = {}
+    local s = ffi.new("int[?]", n / 2)

Увеличивает скорость LuaJIT еще на ~30%

прикольно… но это уже из разряда специфических оптимизаций всё-таки

За счет чего выигрыш?

Убраны разименованния из мултьтитайп в целое буквальном указанием, что таблица конкретно целых массив

так то компилятор, до него еще дело дойдет не сразу.

чем ты засрал систему, если тебе требуется писать полный путь до бинарника?

чё только не придумают, лишь бы не использовать яп копилируемый в натив…

чем ты засрал систему, если тебе требуется писать полный путь до бинарника

Ближе к окончанию тестирования уже ничем, но я не стал редактировать сообщение.