Комментарии 9
А можно в примерах добавить раскраску синтаксиса, поставив у тега source атрибут lang=«cs»?
unsafe void dummy(out int arg)
+3
На мой взгляд, получилась очень хардкорная библиотека, которую весьма тяжело использовать (да и не имеет смысла в обычной жизни). А для внутренних целей гораздо проще написать свой маленький сабсет для конкретной задачи.
Всё-таки в погоне за производительностью в Microsoft написали весьма много опасных вещей, которые в неумелых руках могут их же и оторвать.
В итоге, я в очередной раз прочитал про эту библиотеку и решил, что всё-таки она мне не нужна :)
Всё-таки в погоне за производительностью в Microsoft написали весьма много опасных вещей, которые в неумелых руках могут их же и оторвать.
В итоге, я в очередной раз прочитал про эту библиотеку и решил, что всё-таки она мне не нужна :)
+1
Когда работаешь с сетью и у тебя есть только поток байт — эта библиотека самое то. Кажется в новой версии Protobuf на неё переведут API.
+2
Спасибо за статью, приятно иметь эту информацию на русском языке.
0
Спасибо за статью! В свое время разбирался с Pipelines и в том
единственном посте, который многие перевели и разместили у себяне хватало информации, чтобы погрузиться в разработку и не словить подводных камней.
Для меня например было неочевидно что при использовании PipeReader после каждого Read обязательно надо вызвать AdvanceTo, даже если пришел буфер нулевой длинны (а такое тоже бывает)
0
спасибо за статью
0
Всё пытаюсь понять если смысл самому браться писать, или же подождать чего нибудь официального. Так как просто нет состыковок, но есть официальные extensions что бы преобразовывать Stream в Pipies. Кейс который бы я хотел попробовать в качестве имплементации простой. Берем Stream из HttpClient, прогоняем через пайп и подаем на вход другому Stream, для десериализации. Смогу ли я сэкономить что-то в плане памяти, процесорнного времени?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
System.IO.Pipelines — малоизвестный инструмент для любителей высокой производительности