Size: a a a

2021 July 05

D

Denisio in pro.net
там создание задач и await больше сожрёт чем один call
источник

V

Vyacheslav in pro.net
ок. Убирать не кодить
источник

D

Denisio in pro.net
ну мне кажеца это не то место которое надо инлайнить
источник

D

Denisio in pro.net
бенчмаркать не буду, но почемуто кажеца именно так
источник

VS

Vasily Shapenko in pro.net
Шо у нас тут?
источник

E

EgorBo in pro.net
вячеслав подставляет сишарп
источник

E

EgorBo in pro.net
за это будет расстрелян без суда
источник

K

Katz in pro.net
проще включить анализатор и использовать автоисправление студии,
всяко лучше чем всякие .CAF()
источник

V

Vyacheslav in pro.net
это не избавляет от необходимости везде видеть .ConfigureAwait(false)
источник

K

Katz in pro.net
но добавляет необходимость везде видеть .CAF()
источник

A

Aloraman in pro.net
await SwitchTo.ThreadPool() и забываешь о ConfigureAwait
источник

VS

Vasily Shapenko in pro.net
К сожалению, любой сишарпист так делает
источник

V

Vyacheslav in pro.net
Если в библиотечных методах await через строку, то в исследовательском коде это мешает думать о задаче, имхо. Перед релизом можно и обратно поменять — не вопрос.
источник

K

Katz in pro.net
Оно может нормально выглядеть для тебя, так как ты написал это.
Но для другого разработчика только добавит лишнего повода сказать "а это что за херня?"
источник

K

Katz in pro.net
да, вариант, но легко забыть
источник

V

Vyacheslav in pro.net
Откуда это? Нужно ли везде pool за собой таскать?
источник

K

Katz in pro.net
суть в том, чтобы ты любым способом переключился на дефолтный контекст синхронизации в самом начале метода,
а дальше .CAF() больше не нужен
источник

K

Katz in pro.net
но это менее очевидно, и легко забыть об этом
источник

V

Vyacheslav in pro.net
Хмммм. Пойду со слезой читать доки
источник

RB

Roman Bukin in pro.net
Напиши им ишуй
источник