Comments 11
Интересно что заставляет людей писать статьи про оптимизации без цифр. Ни timeit.timeit(), ни time.perf_counter(), вообще ничего. Мы просто скажем что эта операция долгая, а эта быстрая. Написанному верить. Штамп. Подпись.
Если вам по какой то причине необходимо ломать pythonic way, то вы делаете что-то не то. Не знаете как это написать быстрее на чистом python пишите на чем то еще: cython, C, C++(boost.python), Rust(PyO3). Большая часть примеров из статьи могла быть ускорена иными методами следующими pythonic way.
Если вам по какой то причине необходимо ломать pythonic way, то вы делаете что-то не то. Не знаете как это написать быстрее на чистом python пишите на чем то еще: cython, C, C++(boost.python), Rust(PyO3). Большая часть примеров из статьи могла быть ускорена иными методами следующими pythonic way.
Умные мысли:
— читать из одного большого файла быстрее, чем открывать и читать несколько маленьких
— читайте только то, что надо сейчас а не всё подряд (ленивый импорт)
— если надо запускать CLI много и часто — сделайте его демоном и кормите через канал (pipe)
— вызов функции это долго, всякую мелочь можно писать так (inline)
— поиск атрибута тоже занимает время в интерпретируемых языках
— создание новых объектов занимает время, даже если вы их потом не используете
— использовать ссылки быстрее, чем копировать содержимое
— читать из одного большого файла быстрее, чем открывать и читать несколько маленьких
— читайте только то, что надо сейчас а не всё подряд (ленивый импорт)
— если надо запускать CLI много и часто — сделайте его демоном и кормите через канал (pipe)
— вызов функции это долго, всякую мелочь можно писать так (inline)
— поиск атрибута тоже занимает время в интерпретируемых языках
— создание новых объектов занимает время, даже если вы их потом не используете
— использовать ссылки быстрее, чем копировать содержимое
- не используйте python, если важна скорость?
Мне иногда кажется, что те, кто пишут про оптимизацию на python тупо издеваются...
Вовсе нет. В основном уровень кода в большинстве компаний где я работал настолько низок что написав просто правильно получаешь прирост производительности в 10-20 раз. Нужно просто знать какие операции на python медленные, а какие быстрые. Для большинства типовых вещей все написано на Си. Поэтому в подавляющем большинстве случаев оказывается что тормозит как раз та часть которая не на питоне. Не потому что она не на питоне, а потому что на нее больше всего вычислений падает. Но ее ты уже не можешь ускорить, а писать на питоне все еще можешь. быстро и удобно.
Например. Есть у меня видеопайплайн. Казалось бы какое видео на python. Но декодированием занимается gstreamer данные передаются через tcp сокеты, а основную обработку выполняет opencv, numpy и tensorflow. И в итоге весь код на python занимает 3-5% от общего времени вычисления. С точки зрения бизнеса проще купить железо чуть мощнее чем тратить месяцы человекочасов на оптимизацию в 2%.
Например. Есть у меня видеопайплайн. Казалось бы какое видео на python. Но декодированием занимается gstreamer данные передаются через tcp сокеты, а основную обработку выполняет opencv, numpy и tensorflow. И в итоге весь код на python занимает 3-5% от общего времени вычисления. С точки зрения бизнеса проще купить железо чуть мощнее чем тратить месяцы человекочасов на оптимизацию в 2%.
Спасибо, спасли нам несколько минут жизни!
вызов функции это долго, всякую мелочь можно писать так (inline)
это почти гарантированное убийство читаемости, тут хорошо сказал предыдущий комментатор
Это статья такая :)
Я лично не считаю что это должен делать программист — руками портить код. В идеале интерпретатор/компилятор может это и самостоятельно сделать, можно ему подсказать (как inline в С++) если надо.
Полагаю что со временем:
перестанет быть актуальным, сам Python это оптимизирует. Да и сейчас как хорошо сказал предыдущий комментатор это спорные оптимизации.
Я лично не считаю что это должен делать программист — руками портить код. В идеале интерпретатор/компилятор может это и самостоятельно сделать, можно ему подсказать (как inline в С++) если надо.
Полагаю что со временем:
— вызов функции это долго, всякую мелочь можно писать так (inline)
— поиск атрибута тоже занимает время в интерпретируемых языках
перестанет быть актуальным, сам Python это оптимизирует. Да и сейчас как хорошо сказал предыдущий комментатор это спорные оптимизации.
Демон и канал это вредный путь. Почему бы сразу не написать очередь и воркеры?
Это статья такая :)
Автор описывает сложности при создании CLI (hg) распределенной системы контроля версий Mercurial.
Это собранный PyOxidizer «родной» бинарник, внутри которого запакован Python cо всеми необходимыми библиотеками/зависимостями который собственно и запускается.
Как CLI это не супер-быстро запускается и в этом проблема. Но можно его запустить один раз как демон и кормить через канал (а через что ещё CLI работать должен ?).
Очередь и воркеры можно использовать когда Python уже работает, какое отношение они имеют к изначальной проблеме медленного запуска?
Автор описывает сложности при создании CLI (hg) распределенной системы контроля версий Mercurial.
Это собранный PyOxidizer «родной» бинарник, внутри которого запакован Python cо всеми необходимыми библиотеками/зависимостями который собственно и запускается.
Как CLI это не супер-быстро запускается и в этом проблема. Но можно его запустить один раз как демон и кормить через канал (а через что ещё CLI работать должен ?).
Очередь и воркеры можно использовать когда Python уже работает, какое отношение они имеют к изначальной проблеме медленного запуска?
Ты говорил "Это самый быстрый корабль в галактике"!.
Тише едешь, дальше будешь.
Первое правило оптимизации Python-кода — не использовать Python.
Sign up to leave a comment.
Что я узнал про оптимизацию в Python