Почему lua такой тормоз ?

Какая тебе разница какая там скорость?

Ты сейчас серьёзно?

Ты luaJit используешь? Версию давай и полный кусок кода.

А что, есть сомнения? Lua - язычок для скриптинга, если что-то где-то упирается в его производительность то язык выбран и/или используется неправильно. А если ТС меряет что-то там из праздного любопытства, это достойно порицания вдвойне.

нет просто lua5.3 из консоли ( ну или через lua-nginx). Натравливаешь достаточно большую простыню текста и сравниваешь по времени:

function test(data)
    local ndata = {}
    for row in data:gmatch("[^\r\n]+") do
         table.insert(ndata, row)
         table.insert(ndata,"\n")
    end
    return table.concat(ndata)
end

function test(data)
    local ndata = ""
    for row in data:gmatch("[^\r\n]+") do
         ndata = ndata .. row .. "\n"
    end
    return ndata
end

Какая тебе разница какая там скорость?

Я тоже думал «какая» пока nginx ( с emebd lua ) не уперся в потолок по процессору. Уже и на регэкспы грешил - а оказалось все проще - просто склеивание строк жутко медленно работает.

Lua - язычок для скриптинга

И? По твоему это оправдывает тормоза? Хотя дело вообще не в этом, есть то что он хочет делать через сахар с оверхедом, а есть напрямую через процедуры, хочешь простоты берёшь сахар хочешь скорости берёшь процедуры. Суть вот в этом.

если что-то где-то упирается в его производительность то язык выбран неправильно.

Любая задача упрётся в производительность, любая.

А если ТС меряет что-то там из праздного любопытства, это достойно порицания вдвойне.

Любопытство достойно порицания? Серьёзно? Вот прям не шутишь? Тоесть по твоему интерес для ущербных? То кто хочет что-то знать просто потому что это ему интересно, а не потому что на до это плохо?

Если это действительно так и ты не шутишь. Приятно было познакомится, адьёс амиго.

В Lua строки — неизменяемые объекты, и хранятся в единственном экземпляре. Создание каждой строки достаточно накладное, потому что нужно сначала выяснить, нет ли такой же строки уже. Если есть, новосозданная строка будет ссылаться на это внутреннее хранилище уникальных строк. Зато сравнение строк быстрое, так как не требует сравнивать само содержимое.

Поэтому если ты собираешь длинную строку, быстрее не создавать каждый раз новые, а собрать части в таблицу, содержимое которой потом склеить за один раз. Иначе у тебя будет не просто «в 10 раз медленнее», а O(N²) против O(N).

Ради интереса посравнивай на luajit.

Пистон тоже для скриптинга, но так как он медленнее и жирнее LUA, его не очень любят встраивать.

Я в языке луны и в особенностях его реализации не спец, но походу в первом случае создаётся новая таблица, а во втором - расширяется старая. Наверно тогда первый вариант работает быстрее.

Вместо многословия https://stackoverflow.com/questions/19138974/does-lua-optimize-the-operator

Без обид.

Пистон тоже для скриптинга, но так как он медленнее и жирнее LUA, его не очень любят встраивать.

У питона большая стандартная библиотека, и практически любой существующий скрипт на нее завязан. Чтобы его встроить, недостаточно заюзать libpython (и вдоволь посношаться с GIL в случае многопоточности), надо еще развернуть вместе с придожением кучу скриптов. А в Lua стандартная билиблотека на С, и куча сторонних модулей тоже, если хочется то можно все в один бинарник слинковать

т.е. жабий StringBuilder тебя не смущает?

NGinx умеет применять XSLT-шаблон к списку файлов - не нужно будет никаких LUA-скриптов + работать быстрее будет (см. https://serverfault.com/questions/312796/custom-autoindex-pages-with-nginx/89... например).

Потому что говно-скриптота.

Это не луа тормоз, это программировать надо уметь и узнавать особенности реализации строк. В данном конкретном месте луа ведёт себя как с++/java/c# и овердохрена языков.

И? По твоему это оправдывает тормоза? Хотя дело вообще не в этом, есть то что он хочет делать через сахар с оверхедом, а есть напрямую через процедуры, хочешь простоты берёшь сахар хочешь скорости берёшь процедуры. Суть вот в этом.

Нет, не в этом, а в том что понятие «тормоза» с тому что не является боттлеком вообще не применимо. Поэтому абсолютно наплевать какой там у чего оверхед. Тут только один критерий - понятный и поддерживаемый код.

Любая задача упрётся в производительность, любая.

Наглая и безграмотная ложь. Объяснить почему?

Любопытство достойно порицания? Серьёзно? Вот прям не шутишь? Тоесть по твоему интерес для ущербных? То кто хочет что-то знать просто потому что это ему интересно, а не потому что на до это плохо?

Любопытству можно найти достойное применение, а сравнивать абстрактную производительность абстрактных строчек мало того что к таковым не относится, так ещё и может привести к вредным последствиям, например кто-то может начать уродовать код во имя производительности которую никто никогда не почувствует. Да, это достойно порицания и ущербно, никаких шуток.

адьёс амиго

Когда будет адьёс решу я.

меряет что-то там из праздного любопытства, это достойно порицания вдвойне.

Коверкать слово «мерит» достойно порицания вдвойне.

Это всё что ты можешь сказать по теме?

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

Так это ты писал в 00-х панель управления для SUSE, которая строила список опций дольше, чем загружается система до рабочего стола?

Ты либо намеренно вырвал фразу из контекста, либо не умеешь читать. Там ясно написано условие

что не является боттлеком

Это норма.

просто склеивание строк жутко медленно работает.

Склеивание строк всегда будет работать намного медленнее, чем добавление в хэш-мапу. Это by design.

Исключение составляют только такие sophisticated implementations, как http://www.and.org/vstr/ , где под капотом строится список вместо реального склеивания строк.

Автор наверху пишет, что уперся в производительность луа-кода.

Я отвечаю тебе, а не автору.

А что, ты где-то еще написал «варяет суп» вместо «варит суп» или «собака метяет угол» вместо «собака метит угол»?

А что, тема уже про правописание?

Ты написал:

Какая тебе разница какая там скорость?

Lua - язычок для скриптинга, если что-то где-то упирается в его производительность то язык выбран и/или используется неправильно.

PHP тоже язык для скриптинга. JS еще, Ruby и Python. Давай сразу перепишем весь нагруженный веб на си для производительности? А кто заплатит за это всё?

Есть такой глагол: мерять.

Ну так ты её начал.

Ты написал:

Какая тебе разница какая там скорость?

Lua - язычок для скриптинга, если что-то где-то упирается в его производительность то язык выбран и/или используется неправильно.

PHP тоже язык для скриптинга. JS еще, Ruby и Python. Давай сразу перепишем весь нагруженный веб на си для производительности? А кто заплатит за это всё?

Потрудись-ка объяснить как из того что я написал следует этот бред.

Нет, начал её не я. А вот влез со своими бесполезными замечаниями ты.

Напрямую.

Это не объяснение. Да у тебя его и нет. Потому что никак не следует.

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

А нахрен он тогда нужен, если выходит что нельзя фигак фигак в продакшен.

Что такое просадка производительности? Что такое скриптовые языки? Чем они отличаются от не-скриптовых? Что значит требует? В каких условиях, с какими бюджетами, с каким прогнозом нагрузки?

По чём шланг брал?

Отвечай на вопросы. Твой поставлен некорректно, но я понимаю что это сознательный приём троллинга. Со мной такое не проканает, к твоему огорчению.

Теперь сравни на C++ конкатенацию нескольких std::string с вставкой их в вектор. Результат тоже будет заметна

Ради интереса посравнивай на luajit.

А смысл, JIT может магически ускорить конкатенацию строк?

Причём тут JIT? Это другая реализация и там могли это оптимизировать.

Потому что строки в Lua immutable.

Поэтому первое сначала создает новую строку размером достаточным для ndata + row и пихает туда row и ndata, а следом создает еще одну строку размером ndata + row + «\n» и пихает туда предыдущую и «\n».

Трюк с table.insert - это как StringBuilder в Java. В таблицу пихаешь строки, не создавая временных переменных.

Правда в конце надо собрать все что в таблице в одну строку

s = table.concat(t)

Но эта операция O(N), т.е. сразу создает одну большую строку и пихает все в нее.

Больше информации, например, тут https://www.lua.org/pil/11.6.html.

А Lua как раз быстрая, потому что это Virtual Machine, да еще и «register-based». Ее часто встраивают в игры именно поэтому. Тут можно почитать об этом больше:

Bytecode VMs come in two main flavors: stack-based and register-based. In a stack-based VM, instructions always work from the top of the stack, like in our sample code. For example, INST_ADD pops two values, adds them, and pushes the result.

Register-based VMs still have a stack. The only difference is that instructions can read their inputs from deeper in the stack. Instead of INST_ADD always popping its operands, it has two indexes stored in the bytecode that identify where in the stack to read the operands from.

Register-based VMs got a reputation for being a bit faster after Lua converted to that style

(c) http://gameprogrammingpatterns.com/bytecode.html

Этот оратор всё правильно сказал.

Конкатенировать кучу строк в Lua — признак рукожопия, и о том, что лучше засунуть их в таблицу и потом сконкатенировать с table.concat, написано практически везде. Если неудобен вариант с засовыванием всего в таблицу и последующим table.concat (а это правда не всегда удобно, и вдобавок может быть не очень красиво), сделай объект с удобным тебе интерфейсом (5-10 строчек).

Потому что во втором случае ты используешь излишнюю функциональность.