История изменений

Проблема - определение интерфейса regexec, которое так сделано из-за ограничений С. Так?

Перетак и нет не так :D Lua на том же C и написана и внутри работает как обычный C. Хватит тут выдумывать на пару с debugger :D Ограничения в си какие-то, подстроки медленные, хоспади, у си меньше ограничений чем у любого языка практически, а строки там, во первых их нет, а во вторых они самые быстрые среди всех, в lua есть просто иммутабельность, когда если взята 1 строка раметром 5 байт и она встречается в воде, в коде 1000000 раз то она будет занимать 5 байт и всё.

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

И да в lua нет регрексов там шаблоны, местами похоже, местами очень, делает тоже самое, но не совсем, но в обычных случаях неотличимо, в сложных несравнимо, оно просто разное. Короче дьявол в технических мелочах и оконечной реализации конкретного места. Скорость луа выезжает на алгоритмах тем самым оно нивелирует в целом неспешную работу языка до приличных значений, а обычные С реализации часто опираются на дефолтный перфоманс из коробки, быстро по умолчанию, но как только дело доходит до трансфера данных 10005000 миллиардов аллокаций, деревьев и прочего, начинается адок, (в любом языке) и нужно заруливать оптимизации алгоритмические, но у них есть минус, оптимизации не могут быть общими, они покрывают частные случаи и мне кажется POSIX грепы просто сделаны такими потому что они должны быть универсальны, а скорость работы предсказуема. От и всё.

Просто реализация такая какая есть.

Проблема - определение интерфейса regexec, которое так сделано из-за ограничений С. Так?

Перетак и нет не так :D Lua на том же C и написана и внутри работает как обычный C. Хватит тут выдумывать на пару с debugger :D Ограничения в си какие-то, подстроки медленные, хоспади, у си меньше ограничений чем у любого языка практически, а строки там, во первых их нет, а во вторых они самые быстрые среди всех, в lua есть просто иммутабельность, когда если взята 1 строка раметром 5 байт и она встречается в воде, в коде 1000000 раз то она будет занимать 5 байт и всё. Это плюс, он очень бустит скорость, за счёт исключения трасфера данных и дубликации, часто всё в кешах крутится что в сотни раз быстрее, одна из сравниваемых строк например может 10000000 раз лежать в кеше, практически нулевая стоимость доступа, а там сейчас мегабайты влазазят, вот тебе и буст за счёт локальности данных. Хотя как сказано выше можно и обратный эффект словить бездумно конкатенируя, а это аллокация и поиск существования. Реализация регрексов в POSIX наверное быстрая, а вот подход к данным медленный, наверное если слово встречается 10000000 раз оно столько же раз аллокацию делает, заполняет и что-то там у себя ещё строит, но эт смотреть надо. И да в lua нет регрексов там шаблоны, местами похоже, местами очень, делает тоже самое, но не совсем, но в обычных случаях неотличимо, в сложных несравнимо, оно просто разное. Короче дьявол в технических мелочах и оконечной реализации конкретного места. Скорость луа выезжает на алгоритмах тем самым оно нивелирует в целом неспешную работу языка до приличных значений, а обычные С реализации часто опираются на дефолтный перфоманс из коробки, быстро по умолчанию, но как только дело доходит до трансфера данных 10005000 миллиардов аллокаций, деревьев и прочего, начинается адок, (в любом языке) и нужно заруливать оптимизации алгоритмические, но у них есть минус, оптимизации не могут быть общими, они покрывают частные случаи и мне кажется POSIX грепы просто сделаны такими потому что они должны быть универсальны, а скорость работы предсказуема. От и всё.

Просто реализация такая какая есть.