Комментарии 28
Применение асинхронных механизмов при написании некоей программы означает, что эта программа будет выполняться быстрее, чем без использования подобных механизмов.Нет.
По моему опыту, асинхронность может сделать программу медленнее. А может ничего не изменить. Может ускорить. В таком виде это звучит ни разу не оптимистично — а зачем мне тогда такая штука нужна? =)
ПС: просто это настолько частое заблуждение, что немножко больно каждый раз читать такие вещи.
Правильнее сказать что асинхронность ускоряет программу когда ожидается много задержек, например при ожидания ответа от удаленного сервера. В таком случае можем открыть несколько соединений и в каждом соединении отправлять запрос, ждать ответ, и обрабатывать его - и пока ждем ответ - будем отправлять новый запрос и т.д.
— Отлаживаться очень сложно, код избыточный
— Куча легаси и одноименных структур (к примеру есть два типа Future)
— Есть большие вопросы о том как правильно ловить исключения во вложенных корутинах
— По ощущениям люди пишут код дольше и ловят больше багов именно на асинхронном питоне
— У себя в кампании заметил что рост производительности в проектах на бою не больше 30%
— Очень сложно заставить питон грузить все ядра
— До версии 3.8 не было нормальной возможности в дебаге получить результат асинхронной функции
А вот насчет грузить все ядра, мне так не кажется. Есть ведь модуль multipocessing.
Лично я для себя набросал небольшой фреймворк на его базе (по опыту разработки большой программы, используя опробованные подходы) и планирую польоваться им. Суть — работа выполняется в отдельных процессах, общение через очереди сообщений.
Мне такой подход нравится гораздо больше, чем накидать асинхронных вызовов функций. Главное преимущество такого подхода — можно ясно понимать, когда и что происходит.
А что не так с исключениями? Все на них жалуются, а я вот четыре года юзаю asyncio и проблем не испытывал
Наиболее разумное применение — скрейпинг. Пример: мне нужно было собрать данные с 4К страниц. Запустил синхронный код, вышло около 25 минут до завершения процесса. По результату обнаружил, что забыл еще один параметр прочитать и поэтому надо было повторять заново. Переписал на асинхронный — вышло около 2,5 минут. Ровно в 10 раз быстрее.
Для глубокого и фундаментального понимания асинхрощины питона, а также её исторического контекста, рекомендую прочесть книгу про монументальный фреймворк Twisted от издательства O'Reily. Если вы ещё сомневаетесь, то всё что вам нужно знать, чтобы захотеть почитать — корутины питона проектировали под обратную совместимость с Twisted, и об этом явно указано в документации.
(про await) Такая конструкция означает, что программа будет выполняться до тех пор, пока не встретит await-выражение, после чего вызовет функцию и приостановит своё выполнение до тех пор, пока работа вызванной функции не завершится
Извиняюсь, а разве старый добрый вызов функции не делает вот это самое, что здесь описано?
… После этого возможность запуститься появится и у других корутин.
Одна корутина ждет ответа откуда-нибудь, тем временем другая делает что-нибудь еще.
Асинхронное программирование в Python: краткий обзор