Единственная причина по которой асинхронные задачи могут быть быстрее синхронных - лучшая загрузка процессора. Поэтому в вашем случае проверить очень просто:
1) Написали синхронный алгоритм, посмотрели в Диспетчере задач загрузку CPU.
2) Написали асинхронный алгоритм, еще раз посмотрели.

Более того, вы должны понимать, что async/await - это просто синтаксический сахар, который не дает никакой асинхронности из коробки. async/await действительно становится асинхронным только в том случае, если последний вызов в цепочке является истинной асинхронной операцией (например, вызов операции на асинхронном сокете, отправка какой-то задачи в тред пул, и т.д.).

PallarisДа уж, мастер-класс бенчмаркинга :) Мера скорости решения задачи - тоже по загрузке проца?То есть вы, господин трепло, во-первых, не понимаете чем вызвано ускорение при асинхронных операциях, а во-вторых не отличаете микробенчмарки от макробенчмарков. А зачем тогда пишете здесь и советы даете?

pation,
Что ж, с удовольствием послушаю вашу версию.

П.С.: только убедитесь перед ответом, что вы понимаете разницу между ускорением, то есть уменьшением времени выполнения операции, от отсутствия ожидания, когда задача выполняется столько же времени, но вы просто не ждете ее окончания.

Алексей КcdtyjvЕдинственная причина по которой асинхронные задачи могут быть быстрее синхронных - лучшая загрузка процессора. Ты так ничего и не понял про экономию на ожидающий потоках. В ужасе читай про I/O Completion Ports .О, еще один. Ну давайте, расскажите сколько же составляет эта экономия.
Мы все в свое время оттестировали в том числе и подход с SocketAsyncEventArgs вдоль и поперек на реальной 10-гигабитной сетке. И я скажу вам, что асинхронный сокет не выигрывал ни в одном сценарии. Самая быстрая модель - это обычный блокирующий сокет без всяких ухищрений. Если потоков (читай - соединений) становится уж слишком много, то надо переключаться на неблокирующий сокет с селектором. Так работает подавляющее большинство современных высокопроизводительных серверов. Все. Асинхронный сокет - это гомно на палочке.

В общем, как я понимаю, вы целостно вообще не умеете рассуждать на тему перфоманса. То вам лишний поток с 1Мб стэка это трагедия, то вам IO-порты панацеей являются. Это называется "слышал звон, да не знаю, где он".

Awaiter[Просто хочется четкого подхода... понимания.Попробую максимально просто. У любой асинхронности есть всего навсего два варианта использования:
1) Если надо не ждать результата. Например, мне надо поклеить обои. Руки у меня по этой части из задницы, и я думаю, что у меня (ядро 1) это займет 2 дня. Но тут я решаю взять и попросить своего кореша (ядро 2), который это делает ничем не лучше меня. В итоге, как ни крути на саму задачу все равно уйдет два дня. Но в первом случае я сам это делаю (синхронно), и пока я этим занят, я не могут сделать ничего более. А во втором случае я попросил Васю сделать это за меня, а сам пошел заниматься чем-то другим.
Это типичный паттерн в UI, когда юзер плыкает на кнопку, которая строит охреневший отчет. Если вы будете строить его синхронно - то заблокируете UI на все время его построения, и у юзера начнет нервно подергиваться глаз. А если вы это сделаете асинхрнонно, то пока отчет строится, юзер сможет заняться чем-то другим.
Ускорения нет, просто меняется flow программы.
2) Если надо именно ускорить работу чего-либо, как правило - некоего вычислительного алгоритма. В моем примере это означает, что я позову не одного Васю, а, скажем, 4х. Один будет клеить обои на кухне, второй в детской, и т.д.. И в итоге на все-провсе уйдет на 2 дня, а (2 / 4 + обязательные накладные расходы) ~ 0.7 дня. Почитайте про закон Амдала .
Как правило, такие задачи решаются через подход map-reduce - когда вы сначала бьете большую задачу на маленькие части, которые стараетесь выполнять максимально параллельно. А потом вы собираете результаты, и как-то агрегируете их. Второй подход - событийный. В нем оперируют потоками неких событий. Пример - фреймворк Storm (вбейте в гугле "twitter storm streaming"), разработанный в недрах Твиттера.
Эти подходы именно что ускоряют работу алгоритмов. Вернее сказать - пытаются ускорить. На самом деле, далеко не всегда это возможно и оправдано. Но это уже другой разговор.

Так вы про какую асинхронность спрашивали - про первую или про вторую?