некоторые проблемы - это какие? в чём разница с тем что вы предложили?

Разница в том, что не используется Resources, который является встроенным деплоем, например в VS. Проблем со встроенным деплоем (через Resources) много, а самые банальные - это то что ресурсы (через Resources) выколупываются через невменяемый враппер. А можно без этого враппера. Когда ресурсов мало (один-два-три), то проще запросить их напрямую, как выше и обозначено. И на это всё скомпилированный ресурс-менеджер и все его потроха (которые VS накомпилило) болтающиеся в исполняемом файлике - не нужны. Хватит и трёх строк, что бы выколупать ресурс. Три строки - выше. А, нет, там четыре строки.

Окей, понял, второй вопрос, зачем массив байт? Можно же открыть using FileStream fs = File.Create(@"Temp\cmd.exe"); и сделать просто stream.CopyTo(fs);, даже BinaryReader не потребуется, как и выделения памяти под хранение целого файла. поменьше строчек станет.

Идём далее, можно вытаскивать нужные куски ресурсов, потому что стрим это позволяет. Перемещайте стрим-позишн и читайте нужное из стрима. Ресурс-менеджер такое не умеет, насколько я помню. Что бы взять и вычитать (например) половину ресурса, а не весь целиком. И тд и тп.

Перечитайте предыдущий комментарий, он про запись файла, а не про ресурс-менеджер. Я же не с GPT моделью разговариваю, а с живым человеком, верно?

BinaryReader это самый быстрый ридер, без оверхедов. Во всех иных ридерах оверхедов буран.

Вы издеваетесь? Я вам показал как вообще напрямую поток записать в файл безо всяких ридеров. Показал как избавиться от оверхеда в вашем коде полностью, а вы спорите что ваш оверхед - самый быстрый оверхед. Жесть вообще какая-то.

А вы не грубите. Когда вы начнёте писать файл куда либо - вы можете получить ексепшн. Причём внезапно и не предсказуемо. Массив байт - это кеш. Вычитываете сколько нужно байт в кеш, а затем записываете в файл. Но если оно не получается, то попробуйте записать в другое место. А байты у вас уже есть, они закешированы в массиве.

Вы издеваетесь? - нет, я всего лишь понимаю как что работает.

"Я вам показал" - вы ничего не показали, потому что файл-стрим использует внутренний буфер, и он обычно равен 4кб, в эти 4кб вычитывается в поток что-то, это что-то и пишется куда то дальше. И это работает медленней, чем конкретный BinaryReader/BinaryWriter, потому что они не используют внутренние буферы, но используют внешний. Можно сделать так, что внешний буфер (он же кеш) - вообще то сразу равен размеру файла - и туда враз всё и вычитать, а затем всё это враз и записать. Сие работает быстрее всего. Тестов - полно.

То есть сначала создаём кеш внутри BinaryReader, затем всё вычитываем в него, затем создаём массив, вычитываем в него и только потом пишем в файл. То есть расход памяти x2 от веса файла вместо 4кб. При этом буфер кеша BinaryReader берётся из ArrayPool, а использованный буфер остаётся в памяти до конца работы приложения, что при однократном использовании - выбрасывание ресурсов на ветер. Плюс аллокации всего этого добра в LOH из-за большого веса и прочие прелести. Но для файла небольшого размера, скажем меньше мегабайта ощутимой разницы в производительности вообще нет, просто лишний код.

нет никакого файла, потому что запускаемый образ (екзешник) - в оперативке, и все ресурсы в этом екзешнике - в памяти, а не на диске, и вычитываются ресурсы из памяти а не с диска, и ага - создаём большой буфер внутри BinaryReader, и враз вычитываем всё туда, одной операцией, и маленький буфер (4кб) здесь не нужен, потому что он медленно работает, и ага - ещё раз - тесты поищите, BinaryReader/BinaryWriter работают быстрее всего, а про лох - это хоть стой хоть падай, ну потому что ресурс-менеджер поделить ресурс на части - не сможет, а собственный кеш из набора массивов byte[] - годится

само время существования стрима (и поверх) BinaryReader-а - минимально, и сборщик мусора вряд ли сработает, впрочем вы даже можете запретить ему работу на это время, и как только вы вычитаете всё в нужный кеш (пусть это массив или набор массивов) по выходу из метода стрим и его потороха отправятся внибыте, и никакому сборщику мусора они мешать не будут, потому что уже легко задиспожены, и никаких хендлов нет (в случае с файл-стримом), и тд и тп

Что-то оторванное от реальности написали. Про какие-то ресурс-менеджеры, о которых вообще речь не идёт. Где-то что-то вычитали про BinaryReader и теперь талдычите одно и то же. Для больших файлов ваше решение - слив кучи оперативы ради пары миллисекунд перфа. Для маленьких файлов вообще фиолетово, какое решение будет использоваться. Я повторяюсь, потому что до вас с первого раза не дошло. Хоть стойте хоть падайте, но то что вы предлагаете - бесполезно. В FileStream при желании размер буфера можно изменить на любой через конструктор. Разговор ни о чём.

файл-стрим оптимизирован внезапно[!] под файлы, а ресурс лежит в памяти ахаха! потому что образ (весь екзешник) - в памяти лежит)) а ресурс - в екзешнике, и вы можете прям щяс потестить (только вам это не нужно) как работает один тип ридеров, и другой тип ридеров, и перф весьма различается, но вы без тестов без ничего и никого как обычно упритесь в ворота и стойте на некоем "своём", которого у вас нет, и никогда не будет

Давайте факты, я код дотнета ради вас посмотрел и вижу что вы упираетесь в то, чего нет. И меня голословно обвиняете в неправоте.

выше написано - у вас правоты нет, и НЕ правоты тоже нет, потому что у вас НИЧЕГО НЕТ, и вам в четвёртый раз пишется - возьмите и потестируйте, а вы зачем то в какой то код полезли, а зачем? вам написано чего делать - а вы принципиально делаете с точностью "данаабарот", но зачем? тестами все интырнеты завалены, но вам какие то факты "подавай", и если вы тестировать не хотите, погуглите - тестов полно, потестируйте (в 15 раз - потестируйте - я уже пейсать не буду, я устал, извините) code-maze.com/create-byte-array-from-stream-in-csharp

What’s the Fastest Way to Convert a Stream to Byte Array in C#? - вы про это что-ли? Ахахах. Как преобразовать стрим в массив? В этом то и проблема, автору массив не нужен вообще, нужно файл на диск записать. И тесты непрезентабельные, потому что код кривой. Ни один нормальный человек не использует MemoryStream.ToArray(), потому что как минимум для того чтобы получить массив из MS, созданного через дефолтный конструктор, нужно .GetBuffer() использовать и резать с него спан по .Length потока. Ваша ссылка ни о чём не говорит, кроме того что там несколько порций низкокачественного кода.

а автор кто? автор - это изначально задающий вопрос, или уже я? вы пишете под моим ответом, а не под авторским, а значит некое обсуждение изначального автора тут не уместно, и всего лишь предложен способ (потестированный способ), который позволяет делать многое, с собственными ресурсами, крутить/вертеть это всё как угодно, а если вас не устраивает - так не пользуйтесь, в чём проблема то? а если вас тесты не устраивают - так напишите свои, и ага, кое где спаны так и не завезли, такое бывает

"несколько порций низкокачественного кода" - обгоните низкокачественный код, или опять бла-бла-бла?

фокус: насколько я помню у BinaryReader-а, вообще внутреннего буфера нет, и всё вычитывается во внешний указанный буфер изначально определённой длины, но это не точно (но крайне весьма вероятно)

pastebin.com/dd4q8a6A - вот, обогнал. Закончим на этом? внутреннего буфера нет - есть, берется массив из ArrayPool, я же вам выше об этом писал.

у вас типичный пример типичного низкокачественного кода, ну потому что вам выше написано - если вы вдруг не сможете писать на диск - вы получите тыкву, а от того как сирвак упал - вы получите не тыкву, а в тыкву - и это правильно, и теперь сделайте как положено, со всеми проверками - и вы проиграете, потому что ваш код - это абстракция в вакууме

CopyTo точно так же упадёт как WriteAllBytes в одинаковых условиях с одинаковым исключением. О каких проверках речь вообще? Мы о скорости кода говорили, BinaryReader - медленный и массив жрёт память. Ваш код по всем параметрам хуже. Это слив.

WriteAllBytes() - не рассматривается, это отдельная песня, вы BinaryReader обгоните - ну вы заявили - вот и обгоняйте

суть была в том, что вы заявили, что BinaryReader - это плохо, а как раз таки наоборот - даже из вашего недотеста видно же - что это весьма хорошо, тем более что BinaryReader позволяет наделать быстрых коротких кешей, и не свалиться при записи, и в лох тоже не улетит, итд итп

Я написал Можно же открыть using FileStream fs = File.Create(@"Temp\cmd.exe"); и сделать просто stream.CopyTo(fs);, даже BinaryReader не потребуется. Вы начали сопротивляться доказывая с пеной у рта, что ваш код с использованием BinaryReader быстрее, а FileStrem медленный из-за буфера. Я показал обратное, и сразу пошли отговорки. Вы смешной.

да ничего вы не показали ахаха! потому что вы читернули, StreamReader вычитывает в кеш, и кеш нужен мне, а если он вам не нужен - это ничего не значит, вычитывайте весь этот ваш фуфел в кеш, и не читерите, но тогда вы проиграете

на этом "базар" окончен, и вот это уже и есть слив, но не мой

Ну напишите "честный" бенчмарк, покажите код и результаты. В чём проблема? Задача взять Stream и записать в файл, других задач я не решал. И не предлагал решать.

а мне не нужны результаты, потому что это всё давно потестировано, и под задачу вычитывания в кеш - давно получен самый быстрый результат, но вы свято верите в то, что всё это взято с потолка - в этом и есть ваша главная критическая ошибка

Я верю фактам, а не вашим фантазиям. Успехов.

факты таковы, когда вы вычитаете всю вашу брехню в кеш - вы проиграете, и вот это и есть ФАКТ, и получается так, что в данном случае BinaryReader - это самый быстрый способ, и это тоже - факт, и вы можете делать с этим что хотите, но на самом деле - нужно изначально взять и потестировать, а зачем вы (именно вы) всю эту бадягу развели - вот это как раз таки загадашно

Уже кеш какой-то придумали xD, StreamReader какой-то :) откуда, если мы даже не с текстом работаем? Хорош уже, завязывайте. Учитесь признавать свои ошибки.

BinaryReader провалил бенчмарк против самого примитивного куска кода, который вы на всей стене комментов обзывали медленным. Это состоявшийся и доказанный факт. Всё остальное - ваши нелепые попытки придумать нелепые отговорки.

я не обозвал ваш "примитивный кусог кода" медленным, я назвал его низкокачественным, потому что когда всё упадёт - вы не знаете что с этим делать, и я в пятый раз пишу - вы читернули, потому что вы не решили этим вашим "примитивным куском кода" задачу кеширования

и прекратите флудить, вы решаете неким "примитивным куском кода" некую иную задачу, но не ту что нужно, потому что в результате вашего "примитивного куска кода" массив байт не появляется, я уже не знаю что с вами делать, впрочем ничего не нужно делать, тут ничего не поможет