> Просто моя бытовая задача, не синтетика: распарсить текст (баш) и добавить его
> в жсон (jq) для дальнейшей обработки. Что и как тут совершенно
> не важно, важно то, что 500 строк добавляются до 20 секунд
> в зависимости от успешности компилятора.Не, всё чуть сложнее. Низкоуровневая оптимизация, как и любая оптимизация, совершенно бессмысленна в отрыве от задачи. Любые попытки выделить маленький кусочек из задачи и оптимизировать его будут бессмысленны, до того как ты не прошёлся оптимизацией по задаче в целом, не выбрал алгоритмы и структуры данных, и до того, как ты не провёл профилирование и не выяснил, что эта подзадачка поедает у тебя хотя бы процентов 10 времени.
Когда ты выдираешь из своей несинтетичной бытовой задачи маленькую подзадачку, то эта твоя маленькая подзадачка становится той самой синтетикой. Внутри strcpy есть условный переход, из-за него всё происходит не так быстро, как могло бы. Если ты работаешь с C'шными строками, то процессор копируя его постоянно лочится на этом условном переходе, и по сути у тебя работает один конвеер, и далеко не в полную силу.
Если ты этот strcat срастишь со своим лексером, чтобы они стали единым целым, то есть шансы, что тебе удастся сделать это не добавив к лексеру ни единого условного перехода. Таким образом "пустой" прогон лексера (который обходит все синтаксические конструкции но ничего не делает) будет отличаться от прогона в котором лексер копирует полезные строки куда-то на {0-1 такт} умножить на {количество скопированных символов}. То есть реально при некотором везении его скорость работы будет неотличима от пустого прогона, то есть ты получишь _бесплатный_ strcat. В реальности, правда, будет чуть больше кеша использоваться и надо полагать будут почаще промахи поисходить, и может в результате твой лексер будет под нагрузкой работать на 1% дольше, чем без неё.
Если ты правильным образом подберёшь место куда лексеру надо копировать char'ы -- можно ведь сделать так, чтобы он сразу копировал их в строки вида: "name" = "value", то затем тебе останется взять эти строки и скормить их сисколлу writev. Если тебе удастся прям сразу собирать одну большую строку финального json, то тебе даже не придётся доковыриваться до сисколлов, и ты сможешь сделать это аналогом сисколла write который есть в стандартной библиотеки практически любого языка.
Навскидку я скажу вот что: если у тебя 500 строк добавляются 20 секунд, то там что-то серьёзно не так с парсером и даже если ты проведёшь все низкоуровневые оптимизации, ты сэкономишь допустим 50% времени, строки будут добавляться 10 секунд, и всё равно эти числа будут указывать на то, что с парсером что-то серьёзно не так. То есть на несколько порядков не так. Или может у тебя многие гигабайты bash-кода, и нужные строки там попадаются редко и таким образом у тебя бутылочным горлышком оказывается ввод/вывод, а не парсинг и генерация json?
