Comments 10
simd-json невероятно быстрый, смотришь на ускорение загрузки собственной программы и не веришь тому что оно настолько быстро работает, при этом затраты на интеграцию копеечные. Мы используем simd-json для парсинга особо больших файлов, мелочь и сохранение делаем nlohmann может где-то приходится код написать дважды, но учитывая насколько он простой и быстро пишется можно вообще о этом не думать. Самый лучший путь оптимизации это конечно же делить большие файлы на мелкие по какому-то признаку и грузить во все потоки процессора.
nlohmann помнится бинарь раздувает и время компиляции несколько аффектит если не использовать предварительные декларации. Но удобный, зараза.
Есть приложения в которых важен размер и скорость работы, есть в которых не важен, а важно именно удобство разработки. Мне повезло - делаю второй тип, на фоне Qt который кладется рядом с приложением размер бинаря не важен от слова вообще. А что касается времени компиляции, если вы работаете дома кажется что $650 за топовый 16-ти ядерный процессор не такая большая цена на фоне зарплаты программиста, а если в компании и вам закупают оборудование, то объяснить что разработчики на с++ не работают на калькуляторах обычно то же получается. Маки на М процессорах компилируют намного быстрее к слову, не знаю почему, кланг более быстрый, IO у ядра быстрее или еще что, но маки компилируют прям очень быстро с++, раза в два быстрее чем топовые Ryzen компилятором VS.
Маки на М процессорах компилируют намного быстрее к слову, не знаю почему, кланг более быстрый
В достаточно большом проекте количество ядер уже не играет настолько большой роли, ибо проблема, что многие куски кода тупо не выйдет компилировать/линковать в параллель. Там ещё можно какой-нибудь ninja -j16 , gold, всякие ccache и т.п. Закидать проблему процессорным временем только частично решает её.
Ну а не cmake проект на маке компилировать так и вовсе смерти подобно, ибо Xcode кусок тормозов выдаваемый за IDE, хотя там и форкнутый clang под капотом.
Оказывается, интуиция dtolnay основывалась на посте, в котором исследовались разные реализации стандартной Сишной функции strlcpy и выяснилось, что двухпроходный алгоритм оказался быстрее однопроходного.
Вчера на Хабре выложили перевод этого поста.
Круто, может придется что-нибудь заюзать в quick-xml. Давно думаю, где бы найти понятные описания техник оптимизации для быстрого поиска подстрок, с чего вообще подступать. Там тоже есть задача проверить вход на корректность допустимым XML символам.
Странно, что компилятор сам не разворачивает цикл в вызов функции, как это нередко делает gcc.
memrchr точно корректно работает с utf8 строками?
Как я ускорила парсинг строк в serde_json на 20%