Я нашел запись в блоге, которая предполагает, что иногда компилятор c # может решить поместить массив в стек вместо кучи:
Повышение производительности за счет распределения стека (.NET Memory Management: Часть 2)
Этот парень утверждает, что:
Компилятор также иногда решает поместить вещи в стек самостоятельно. Я провел эксперимент с TestStruct2, в котором выделил как небезопасный, так и обычный контекст. В небезопасном контексте массив помещался в кучу, но в обычном контексте, когда я смотрел в память, массив фактически был размещен в стеке.
Может ли кто-нибудь это подтвердить?
Я пытался повторить его пример, но каждый раз, когда я пытался, массив выделялся в куче.
Если компилятор c # может сделать такой трюк без использования ключевого слова unsafe, я особенно заинтересован в нем. У меня есть код, который работает на многих маленьких байтовых массивах (длиной 8-10 байт), и поэтому использование кучи для каждого нового байта [...] - пустая трата времени и памяти (особенно то, что каждый объект в куче имеет 8-байтовые издержки нужен для сборщика мусора).
РЕДАКТИРОВАТЬ: Я просто хочу описать, почему это важно для меня:
Я пишу библиотеку, которая взаимодействует со смарт-картой Gemalto.NET, в которой может работать код .net. Когда я вызываю метод, который возвращает что-то, смарт-карта возвращает 8 байтов, которые описывают точный тип возвращаемого значения. Эти 8 байтов рассчитываются с использованием хеша md5 и конкатенации некоторых байтовых массивов.
Проблема в том, что когда у меня есть неизвестный мне массив, я должен сканировать все типы во всех сборках, загруженных в приложение, и для каждого я должен вычислять эти 8 байтов, пока не найду тот же массив.
Я не знаю другого способа найти тип, поэтому я пытаюсь максимально ускорить его.