[quote источник ] BinaryReader.ReadBytes with PtrToStructure

[/quote]

Правильно ли я понимаю, что:
1 - метод Marshal.PtrToStructure вернул резльтат, который явным образом был приведен к типу структуры
2 - значение, уже приведенное к типу структуры, в виде структуры копируется (value, non-reference copy) в локальную переменную (s)?

Antonariyне копируется, s указывает туда же, куда и buff.Очень хотелось бы в это верить, но увы, не верится. Возможно, Вы сможете дать какую-то ссылку на факты? Мне не удалось найти доказательства.

Antonariy,

вообще мне надо из stream'а по-быстрому прочитать в массив структур. и желательно сделать это за один раз, а не так, чтобы по чтению на каждый элемент массива. В идеале хотелось бы зафиксировать массив структур /* fixed() {...} */, и далее представить указатель на первый элемент массива как указатель типа byte*
Правда дальше непонятно что с этим указателем на байты делать, т.к. это не совсем byte[], и указать byte* в качестве буфера методу stream.Read не получится.
Кругом засада..

Где-то в степи, мне порциями не надо (там порций - немерено)

Где-то в степиRubinDm, если порций немеренно, накой на кой их тащить в массив, вы как лохо как
Где-то в степизагубите свой lohс _уяли? я разве говорил о чтении всего стримА за раз в один массив?
Где-то в степиВы не знаете что такое чанкованииеа - лезете туда.ну, куда уж нам до вас) этож тока вы тут девок голых видывали, а мы так, лохи кругом ))
Где-то в степисам поток это по существу проекция памяти где сидит массив значенийэто мне не интересно, т.к. 1 - я это давно знаю без вас, 2 - оно мне в данном случае не сильно годится. У меня нет проблемы необходимости чтения из дофига диска в дофига оперативы.. ну НЕТУ такой задачи.. решается задача совсем другая: как представить массив структур в виде масива байтОВ, чтобы БЕЗ ЛИШНИХ копирований байтов стрим читал бы прямиком в массив структур. и НЕ надо мне тут рассказывать и предлагать бинари ридеры, MMFы и прочие полезные, хорошие вещи в стиле поштучной выкладки аля "получайте структуру и заносите ее в массив". В моем случае будет достаточно просто ТУПО прочитать из стрима кусок байтов вменяемого размера в массив структур\и байтов по совместительству.
зы: ищо раз назовешь лохом - прокляну ;)

Изопропил1)собственно структуру показал бы


Изопропил2) немеряно - это сколько? файл ~ от 250Мб и до гига - всякий раз по разному.
Изопропилпорция - это что, массив структур фиксированной длины?да. скажем вычитывать надо по 2000шт структур за раз. по оперативе не особо накладно, и хватает на долго (алгоритму расчета). Потом я этот блок 2000*28 выкину в пул и снова заюзаю при загрузке и обработке очередной порции данных. собсно так оно уже и работает на ура. Но вот если бы еще натянуть чтонить типа Union'а на массив байтов и массив структур.. и читать в массив байтов - было бы идеально. но пока не получается. Потому приходится вычитывать 2000*28 байтов в отдельный массив, из которого потом данные через Buffer.MemoryCopy(...) сливаются в массив структур. Что не идеально (и по большему счету не нужно). Это не сильно добавляет расходов, но все-таки...

Где-то в степи, а вообще MMF - это объективно толково, по идее так и надо, что-то подзабыл я про них..)

ИзопропилRubinDm, пущай маршаллер пашет :) ...угу.. пробовал. в принципе - да, можно, с оговоркой что оно наверняк тож копирует ;) хотя не факт, но лимитов времени на ниокры уже маловато. + под .net 6 я словил массу глюканов в стиле "опа_clr_упало__вы_не_виноваты__позвоните_в_microsoft". Под .net 4.5 все ок. По перфомансу +пшик, все тож самое, как если тупо читать в byte[] без форматирования и затем копировать в struct[] предварительно зафиксив их оба. по факту диф в скорости реально на грани погрешности. Попробовал еще MMFы, о которых мне напомнили - получилось реально толково, особо если учесть, что там есть generic-методы, которые умеют принимать на вход структуры (которые параметры genericа) и читают прямиком в них. По ходу это ровно то что мне нужно, и сдается мне без излишних операций переливания из пустого в порожнее.

ИзопропилRubinDm, использование MMF в данном случае (ReadArray<T>)- тоже копирование, "переливание из пустого в порожнее"наверняка. но отрабатывает по факту мгновенно, настолько мгновенно, что становится по большому счету просто пофигу, как именно оно это делает.

[quot Где-то в степи]RubinDm, какой смысл читать кусками с потока в массив байт потом преобразовывать в структуры, когда есть поток он и есть массив байтов и есть параметр сдвижки, все очень просто и примитивно, без всякого засорения памяти.
при одно проходном исследовании потока на коайсемь 10 миллионов структуробайтов исследуется меньше трех секунд.
[spoiler ]
В моем конкретном случае все чуток сложнее. мне надо построить конвеер. на входе - стрим со стуктурирными данными. Это может быть что-угодно, например, последовательные показания с каких-то датчиков на производстве. К каждому элементу последовательности применяется некий алгоритм преобразования элемента (по факту - делегат и, само собой, параметрами делегата являются ref входящей структуры и out исходящей структуры, типы которых, само собой, также являются параметрами ШАБЛОНА делегата). На выходе получаем преобразованные делегатом новые элементы новой последовательности, которые, как не трудно догадаться, подаются на вход следующего этапа конвеера. ФИШКА в том, что конвеер состоит по меньшей мере из 10 станков (делегатов), и половина из этих делегатов, увы, хочет на вход не только очередной элемент из исходной последовательности, но еще и предыдущие элементы в N-горизонте, который задается параметром для всего конвеера в целом или для конкретного станка. Таким делегатом может быть например алгоритм вычисления плавающей средней величины, которую невозможно вычислить только лишь из текущего элемента. Как следствие - такой делегат вынужден обращаться к исходной последовательности с тем, чтобы прочитать элементы в горизонте от текущего. В итоге количество обращений к элементам последовательности сильно возрастает (в N раз), и требования в части производительности к механизмам чтения элементов последовательности растут соответственно. Каждый вызов каждого метода в итоге реально в легкую выпиливает i7. И львиная часть расходов - это инфраструктурные расходы на вызовы методов. Поэтому приходится экономить на вызовах, в т.ч. на вызовах методов IO, и (!) особенно на вызовах реализаций IEnumerator. От всех этих плюшек приходится отказываться. И если есть возможность за раз прочитать не 1, а 1000 записей и закешить их в массив, то так и надо делать.
зы: задача уже реализована в виде шаблона (с параметром типа структуры), под капотом MMF и разумный кеш прочитанных структур. Работает на ура.
Из нерешенного на данный момент: делегаты (станки) - они все, как правило предельно простые (элементарная арифметика, + вычисление средних величин с горизонтами не более 32). количество возможных делегатов ограничено и поддается перечислению. Т.е. в принципе вместо самого делегата на очередном этапе конвеера можно было бы указывать не сам делегат, а константу, определяющую делегат с тем, чтобы станок мог быть реализован в виде switch'а по константе с вызовами соответствующих константам делегатов. Это может оказаться _очень_ полезно, т.к. появляется возможность вправить компилятору мозг на тему встраивания кода делегатов в тело станка (MethodImpl.AgressiveInlining), что сводит количество вызовов делегатов к нулю и дает бешеный рост в производительности. Насколько я понимаю, организовать Inline-вызов делегата, который был указан в качестве параметра, в принципе не возможно. И увы, но в случае работы с шалонами засада в том, что организовать AgressiveInlining не так-то просто. По крайней мере я пока еще не понимаю, как это можно было бы сделать. Но даже тот результат, который достигнут без AgressiveInlining, уже можно считать удовлетворительным.