Комментарии 22
В растовом коде я вижу деление одной и той же переменной в цикле. Это убивает производительность (для этой операции) примерно в 5 раз. Деление (или взятие остатка от деления) в конвейре занимает 2 тика, деление для зависимого значения (т.е. деление результата предыдущего деления) занимает 20+ тиков.
Возможно, все конвертации можно заменить на lookup-таблицы (т.е. month_str = month_lookup[month])
А можете поделиться ссылкой или подробностями, почему так?
Я это для себя обнаруживал, отлаживая tight loop в графическом коде (где надо быстро-быстро считать точки, хотя бы 60 кадров в секунду).
С ходу нашёл вот это: https://www.geeksforgeeks.org/computer-organization-and-architecture-pipelining-set-2-dependencies-and-data-hazard/
А сами цифры вот: https://www.agner.org/optimize/instruction_tables.pdf
Для IDIV там IDIV r64/m64 2 9-17 7-12 (2 тика в pipeline, 7-12 если сделать для data dependency)
Спасибо за идею и ссылки. Обязательно попробую!
Результаты профайлинга (cprofile):
прокомментируйте пожалуйста, где на этом выводе cProfile видны тормоза преобразования в Json ? (не сарказм, серьезно)
Очень странная подсветка в блоках кода на Rust. Буквально 2-3 слова подсвечивает, остальное серое. Это у меня баг или автор выставил не Rust в качестве языка для них?
По поводу сериализации даты на Rust:
Массив лучше всего сразу заводить динамический: `vec![0; 30]`. Затем поглащать его через String::from_utf8_unchecked. Во-первых, не породим лишнюю копию данных, во-вторых, избежим ненужных проверок.
HashMap лучше сразу создать с HashMap::with_capacity(1);
Лишние переменные: month_array, day_array и другие.
Про деление уже выше сказали
Каждый раз интересно, что мешает сразу писать на чём-то более производительном, хотя бы на Java/.Net.
А мне так же забавно наблюдать как разработчики сначала берут Java/.Net, тратят буквально недели на обсуждения очередного интерфейса или абстрактного класса, чтобы достичь необходимой гибкости архитектуры. И в конечном итоге всё равно из-за нехватки производительности изучают твики виртуальной машины, изобретают всякие костыли для ручного управления памятью и прочее.
Пренебрежительное отношение к скриптовым языкам может быть разве что от незнания бытовой мудрости — какой бы язык не выбрал, всё равно найдутся функциональные блоки, которые будет выгоднее переписать на другом языке.
Тут виноваты скорее даже не сами разработчики, а аналитики, которые не смогли заранее, до начала разработки, предсказать нагрузку на продукт/модуль.
Если на проекте неделя тратится на обсуждение интерфейса или абстрактного класса — виноват точно не язык. Просто попались такие разработчики, которым больше нравится обсуждать интерфейсы чем работать.
И да, ваш комментарий выглядит так, как будто разработчики на скриптовых языках не обсуждают неделями абстрактные классы — а это не так. Я даже сталкивался с такими коллегами на проекте...
Потому что это быстрее. На питоне скорость разработки в разы быстрее, чем на "нормальных компилируемых языках". А оптимизация потом может и не потребоваться вовсе. А может и потребоваться, но без применений другого языка, например, с помощью специальных библиотек. Ну а если уже совсем ничего не помогает, тогда только вспоминаем про C и Rust. В итоге конечный результат достигается быстрее, и намного.
(Ничего не имею против "нормальных компилируемых языков", я их тоже очень люблю :))
Сарказм? Прежде чем понять, что появились(возникли) проблемы в производительности в том или ином конкретном месте, проект должен уже работать хотя бы как внутренний MVP. Очевидно, что на C и так далее, вы более или менее сложный проект - будете только дописывать, когда "клиенты" уже будут пользоваться проектом, а автор только лишь тюнить узкие места.
Ускоряем сериализацию JSON в Python с orjson и Rust