Почему асинхронное программирование быстрее

Question

Я продолжаю слышать, что использование шаблонов асинхронного программирования заставит мой код работать быстрее. Почему это так? Не должен ли тот же самый точный код работать в любом случае, выполняется ли он сейчас или запускается позже?

Answer 1

Это не всегда быстрее. Фактически, просто настройка и отключение асинхронной среды добавляет много времени на ваш код. Вам нужно открутить новый процесс/поток, настроить насос очереди событий/сообщений и в конце очистить все. (Даже если ваша фреймворк скрывает от вас все эти детали, они происходят в фоновом режиме).

Преимущество блокировка. Лот нашего кода зависит от внешних ресурсов. Нам нужно запросить базу данных для обработки записей или загрузить последнюю версию чего-либо с веб-сайта. С момента, когда вы запрашиваете этот ресурс для получения информации, пока не получите ответ, ваш код не имеет ничего общего с. Он блокирует, ожидая ответа. Все время ваша программа тратит на блокировку полностью впустую.

Это то, что предназначено для async. Путем поворота кода «wait the this blocking operation» в async-запрос вы оставите все остальное неблокирующее код.

Как метафора, представьте себе менеджера, говорящего своему сотруднику, что делать в этот день. Одной из задач является телефонный звонок в компанию с длительным временем ожидания. Если бы он сказал ей сделать звонок синхронно, она позвонит, и ожидают ожидания, ничего не делая. Сделайте это асинхронным, и она может работать над множеством других задач, пока телефон сидит на удержании в фоновом режиме.

Answer 2

Он выполняет тот же код, но не дожидаясь завершения задачи времени. Он будет продолжать выполнять код до тех пор, пока не будет выполнена асинхронная функция.

Answer 3

Это не быстрее, это просто не теряет времени.

Синхронный код прекращает обработку при ожидании ввода-вывода. Это означает, что когда вы читаете файл, вы не можете запускать какой-либо другой код. Теперь, если вам нечего делать, пока этот файл читается, асинхронный код не купит вам ничего.

Обычно дополнительное время процессора, которое вы можете использовать, полезно для серверов. Поэтому возникает вопрос, почему асинхронное программирование вместо запуска нового потока для каждого клиента?

Оказалось, что запуск и срыв нитей дорог. Некоторое время назад в начале 2000-х годов тест веб-сервера обнаружил, что tclhttpd выгодно отличается от Apache для работы с файлами статического изображения. Это несмотря на то, что tclhttpd был написан в tcl, а Apache был написан на C, а tcl, как известно, был в 50 раз медленнее, чем C. Tcl удалось сохранить свой собственный против Apache, поскольку tcl имел простой в использовании асинхронный API ввода-вывода. Так tclhttpd использовал его.

Это не значит, что C не имеет асинхронного API ввода-вывода. Просто они редко используются. Поэтому Apache не использовал его. В наши дни Apache2 использует асинхронный ввод-вывод внутри себя вместе с пулами потоков. C-код выглядит более сложным, но он быстрее - извлеченный урок.

Это приводит нас к недавней одержимости асинхронным программированием. Почему люди одержимы этим? (большинство ответов на Stackoverflow о программировании javascript, например, настаивают на том, что вы никогда не должны использовать синхронные версии асинхронных функций).

Это связано с тем, что вы редко видите асинхронные программы на C, даже если это лучший способ делать вещи (код GUI - это исключение, поскольку библиотеки пользовательского интерфейса на раннем этапе узнали о асинхронном программировании и событиях). В C существует слишком много функций, которые являются синхронными. Поэтому, даже если вы хотите выполнить асинхронное программирование, вы в конечном итоге вызовете синхронную функцию раньше или позже. Альтернативой является отказ от stdlib и создание собственных асинхронных библиотек для всего: от ввода/вывода файлов до сетей с SQL.

Таким образом, в таких языках, как javascript, где асинхронное программирование заканчивается как стиль по умолчанию, существует давление со стороны других программистов, чтобы не испортить его и случайно ввести синхронные функции, которые трудно интегрировать с асинхронным кодом, не теряя при этом большой производительности , Таким образом, в конце, как и налоги, асинхронный код стал социальным контрактом.