Pull to refresh

Comments 9

Привет. Это моя же статья на dev.to, забыл указать что это перевод

unsafeand и and fixed

Поправьте

Итак, предположим, у нас есть класс с массивами и структура с массивами . В первом случае массивы будут храниться в оперативной памяти нашего приложения, а во втором — в кэше процессора

Не понятно что тут хотел сказать автор. Массив является ссылочным типом и всегда хранится в куче, не важно, откуда на него ссылка. Кэш не управляется CLR и не связан с классами и структурами.

Массив может храниться на стеке при stackalloc ключевом слове, но будет либо unsafe pointer T, либо Span<T>. Незнаю насчет своих структур - с большинством дотнетовских стандартных работает.

Но у автора конечно какая-то неразбериха в оригинале))

stackalloc или нет, это всё еще никак не связано с кэшем процессора или оперативной памятью, ортогональные вещи.

ToArray()метода, чтобы избежать создания лишнего списка.

ToArray под капотом - это простой ToList().ToArray(), так что там не просто создается лишний список, там трафика памяти в 2 раза больше.

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

Я даже не знаю что спросить первым... Т.е. второй вариант не хранит данные в оперетивной памяти? Т.е., в первом варианте данные не будут попадать в кеш процессора?

в наши дни процессоры стали гораздо умнее взаимодействовать с компиляторами

Как именно процессоры взаимодействуют с компиляторами?

использование unsafeкода может значительно повысить производительность

Но явно не приведённый пример.

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

Зачем компилятору угадывать это?

Структуры же не столько хороши в доступе к данными, сколько в своей природе: они являются значимыми типами, т.е. выделяются и хранятся "на месте", вне зависимости от того, где это место.

Эффективный доступ к ним исходит из этого свойства, поскольку массив таких структур обладает высокой локальностью кеша при последовательном обходе (но и сам массив весит больше, что делает реаллокацию массива дорогим).

>Итак, предположим, у нас есть класс с массивами и структура с массивами . В первом случае массивы будут храниться в оперативной памяти нашего приложения, а во втором — в кэше процессора (с учетом некоторых особенностей сборки мусора, которые мы обсудим ниже).

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

1. Структуры не хранятся в оперативной памяти?
2. Структуры гарантированно находятся в кэше процессора?
3. Классы не могут помещаться в кэш процессора?

Вопросы-вопросы...

Когда не следует заменять классы структурами:

  • В структурах есть ссылочные типы, такие как String.

А почему не надо заменять классы структурами, если в структуре есть ссылочные типы? Что плохого случится, если я заменю record User(string Name, int Age) на readonly record struct User(string Name, int Age) ?

Sign up to leave a comment.

Articles