Да, думали на одни рельсы переставить, приценивались. По итогу я, как техлид, считаю это не рациональным. В тексте есть целый абзац об этом. Проблему исправили наименее затратным способом (заменой regex на Boost.Spirit). Альтернативами были либо всё на Boost.Spirit переписать, либо всё на flex+bison. Но трудоёмкость и риски очень велики (работает - не трогай). Переписывать такой критический блок кода только ради красоты и единообразия не стали.
Были рассмотрены несколько библиотек для парсеров, выбор в пользу Boost.Spirit был сделан по таким основным критериям: 1. Он сразу является C++ кодом без кодогенерации. 2. Boost уже используется в проекте. 3. Грамматики получаются достаточно понятные и их легко поддерживать-модифицировать. 4. В тестах он показал очень хорошую производительность.
Для сравнению производительности сначала в общую ветку были влиты бенчмарки (на базе Google Benchmark), потом в ветке эти же бенчмарки прогонялись и сравнивались. Бенчмарки на эти и другие места регулярно выполняются на CI, деградации отслеживаются.
По поводу графа, он не является частью DOM, а строится динамически рядом для вычислений. Сами узлы довольно компактные, расположены по значению в хеш-мапе. Умных указателей там нет, используются сырые указатели на элементы DOM, это не проблема, потому что соответствующие части графа перестраиваются при изменении DOM. Арены (или memory pool) не используются. Прототипы показали, что оно того не стоит: код становится сложнее, а эффект едва заметен.
Я привёл понятные английские варианты названий функций, аналогичными Excel. Если вам привычнее русские варианты, то конечно же в программе такие переводы есть для всех поддерживаемых функций.
Самые лучшие и важные оптимизации - алгоритмические. Они могут дать прирост и в разы и на порядки. О чём очень кратко и незаслуженно мало сказано в последнем абзаце. Много раз встречался, когда для программистов оптимизация - это только вот эти технические приёмы, но это не так. Они способ выжать последние проценты.
Да, думали на одни рельсы переставить, приценивались. По итогу я, как техлид, считаю это не рациональным. В тексте есть целый абзац об этом. Проблему исправили наименее затратным способом (заменой regex на Boost.Spirit). Альтернативами были либо всё на Boost.Spirit переписать, либо всё на flex+bison. Но трудоёмкость и риски очень велики (работает - не трогай). Переписывать такой критический блок кода только ради красоты и единообразия не стали.
Были рассмотрены несколько библиотек для парсеров, выбор в пользу Boost.Spirit был сделан по таким основным критериям:
1. Он сразу является C++ кодом без кодогенерации.
2. Boost уже используется в проекте.
3. Грамматики получаются достаточно понятные и их легко поддерживать-модифицировать.
4. В тестах он показал очень хорошую производительность.
Для сравнению производительности сначала в общую ветку были влиты бенчмарки (на базе Google Benchmark), потом в ветке эти же бенчмарки прогонялись и сравнивались. Бенчмарки на эти и другие места регулярно выполняются на CI, деградации отслеживаются.
По поводу графа, он не является частью DOM, а строится динамически рядом для вычислений. Сами узлы довольно компактные, расположены по значению в хеш-мапе. Умных указателей там нет, используются сырые указатели на элементы DOM, это не проблема, потому что соответствующие части графа перестраиваются при изменении DOM. Арены (или memory pool) не используются. Прототипы показали, что оно того не стоит: код становится сложнее, а эффект едва заметен.
Спасибо за оценку!
Я привёл понятные английские варианты названий функций, аналогичными Excel. Если вам привычнее русские варианты, то конечно же в программе такие переводы есть для всех поддерживаемых функций.
Самые лучшие и важные оптимизации - алгоритмические. Они могут дать прирост и в разы и на порядки. О чём очень кратко и незаслуженно мало сказано в последнем абзаце. Много раз встречался, когда для программистов оптимизация - это только вот эти технические приёмы, но это не так. Они способ выжать последние проценты.