Использование Struct в сценариях для классов. Можно ли избежать boxing?

@IcyWind · Регистрация: 19.09.2011

Студворк — интернет-сервис помощи студентам

Здравствуйте. Есть сценарий, для которого идеально подходят классы, а именно:
-базовый класс с 5-7 наследниками. Эти классы содержат только поля.
-полиморфный контейнер на основе базового класса
-ну и, собственно, работа с полиморфным контейнером(в основном, на чтение и на linq запросы Any)
Я знаю, что если в лоб заменить классы структурами, а базовый класс интерфейсом, то при моих сценариях (обращение к структуре через интерфейс) будет происходить boxing.
сам вопрос: возможно ли как-то в данном сценарии заменить классы на структуры (с целью увеличения производительности), предотвратив при этом boxing при обращении к элементам полиморфного контейнера?

Psilon · 19.10.2013, 19:12

IcyWind, разрешите вам ответить фотографией, лень шерстить файнридером:

Psilon · 19.10.2013, 19:14

Так что ответ: при использовании полиморфизма избежать упаковки не получится.

@IcyWind · 19.10.2013, 23:00 **[ТС]**

Понятно. Да, от классов никуда не деться...тем более, что ещё очень кстати придутся различного рода Dictionary .А давайте уйдём немного от практики в сторону рассуждений)). Немного подумал и появилась идея сделать что-то типо

C#
1
2
3
4
5
6
struct somestruct
{
int a;
bool b;
MyClassBase ClassInfo;
}

То есть идея какая: т.к. в полиморфном контейнере чаще всего используются именно те значения, которые я хочу вынести в структуру, то было бы неплохо хранить их не по ссылке. А, если уж понадобится значения уникальных для каждого из ныне-существующих классов значения, то уж лезте в ссылку на класс, которая хранится в структуре.
В принципе, такой вариант неплох. Но... (дальше рассуждения на основе обрывочных знаний о структурах C#, пожалуйста, исправляйте, если что-то не так)
если я, опять же, сделаю, скажем

C#
1
List<somestruct> a

и начну с ним работать, то что я получу при вызове

C#
1
a[10]

Копию структуры, которая там сидит? Изменять её я не собираюсь...но копия...это же затраты производительности? Значит, создавать список из структур и обращаться к ним по индексу плохая идея. Что остаётся? Остаётся Foreach, а вместе с ним все методы расширения (а главное,Linq).
Вывод делаю такой, что подобный механизм может иметь право на жизнь только в рамках частого использования Foreach для массивов.
Прокомментируйте, пожалуйста, мои догадки и исправьте ошибки))

Psilon · 19.10.2013, 23:10

IcyWind, работа со структурами всегда выше, чем с ссылочными типами. Даже если происходит копирование при присваивании. Запомните: преждевременные оптимизации - зло. Нужно реализовывать наиболее "чисто" все, что нужно. А когда все реализовано, можно и оптимизировать то, что нужно. Не перестаю приводить Фаулера:

С рефакторингом обычно связан вопрос о его влиянии на производительность программы. С целью
облегчить понимание работы программы часто осуществляется модификация, приводящая к замедлению
выполнения программы. Это важный момент. Я не принадлежу к той школе, которая пренебрегает
производительностью в пользу чистоты проекта или в надежде на рост мощности аппаратной части.
Программное обеспечение отвергалось как слишком медленное, а более быстрые машины устанавливают свои
правила игры. Рефакторинг, несомненно, заставляет программу выполняться медленнее, но при этом делает ее
более податливой для настройки производительности. Секрет создания быстрых программ, если только они не
предназначены для работы в жестком режиме реального времени, состоит в том, чтобы сначала написать
программу, которую можно настраивать, а затем настроить ее так, чтобы достичь приемлемой скорости.

Мне известны три подхода к написанию быстрых программ. Наиболее трудный из них связан с ресурсами
времени и часто применяется в системах с жесткими требованиями к выполнению в режиме реального времени.
В этой ситуации при декомпозиции проекта каждому компоненту выделяется бюджет ресурсов - по времени и
памяти. Компонент не должен выйти за рамки своего бюджета, хотя разрешен механизм обмена временными
ресурсами. Такой механизм жестко сосредоточен на соблюдении времени выполнения. Это важно в таких
системах, как, например, кардиостимуляторы, в которых данные, полученные с опозданием, всегда ошибочны.
Данная технология избыточна в системах другого типа, например в корпоративных информационных системах,
с которыми я обычно работаю.

Второй подход предполагает постоянное внимание. В этом случае каждый программист в любой момент
времени делает все от него зависящее, чтобы поддерживать высокую производительность программы. Это
распространенный и интуитивно привлекательный подход, однако он не так хорош на деле. Модификация,
повышающая производительность, обычно затрудняет работу с программой. Это замедляет создание
программы. На это можно было бы пойти, если бы в результате получалось более быстрое программное
обеспечение, но обычно этого не происходит. Повышающие скорость усовершенствования разбросаны по всей
программе, и каждое из них касается только узкой функции, выполняемой программой.

С производительностью связано то интересное обстоятельство, что при анализе большинства программ
обнаруживается, что большая часть времени расходуется небольшой частью кода. Если в равной мере
оптимизировать весь код, то окажется, что 90% оптимизации произведено впустую, потому что
оптимизировался код, который выполняется не слишком часто. Время, ушедшее на ускорение программы, и
время, потерянное из-за ее непонятности - все это израсходовано напрасно.

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

Начинается все с запуска программы под профайлером, контролирующим программу и сообщающим, где
расходуются время и память. Благодаря этому можно обнаружить тот небольшой участок программы, в
котором находятся узкие места производительности. На этих узких местах сосредоточиваются усилия, и
осуществляется та же самая оптимизация, которая была бы применена при подходе с постоянным вниманием.
Но благодаря тому, что внимание сосредоточено на выявленных узких местах, удается достичь больших
результатов при значительно меньших затратах труда. Но даже в этой ситуации необходима бдительность. Как
и при проведении рефакторинга, изменения следует вносить небольшими порциями, каждый раз компилируя,
тестируя и запуская профайлер. Если производительность не увеличилась, изменениям дается обратный ход.
Процесс поиска и ликвидации узких мест продолжается до достижения производительности, которая
удовлетворяет пользователей. Мак-Коннелл [McConnell] подробно рассказывает об этой технологии.

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

Я пришел к выводу, что рефакторинг позволяет мне писать программы быстрее. На некоторое время он
делает программы более медленными, но облегчает настройку программ на этапе оптимизации. В конечном
счете достигается большой выигрыш.

@IcyWind · 19.10.2013, 23:32 **[ТС]**

Сообщение от Psilon

Нужно реализовывать наиболее "чисто" все, что нужно. А когда все реализовано, можно и оптимизировать то, что нужно

Да, полностью согласен

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

Спасибо за замечание, что

Сообщение от Psilon

работа со структурами всегда выше, чем с ссылочными типами

Думаю, что попробую этот подход.
Но, как и сказано в книге,

Сообщение от Psilon

Если производительность не увеличилась, изменениям дается обратный ход

P.s. А что касается моих рассуждений: только что проверил код

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
class b
    {
 
    }
 
    struct SomeStruct
    {
        public int i { get; set; }
        public bool b { get; set; }
        public b Class { get; set; }
 
        public void ChangeStruct()
        {
            Class = null;
            i = 1000;
        }
    }
    
    public class Program
    {
        static void Main(string[] args)
        {
            var a = new List<SomeStruct>();
            a.Add(new SomeStruct() { i = 10, b = true, Class = new b() });
            a[0].ChangeStruct();
            foreach (var item in a)
            {
                item.ChangeStruct();
            }
        }
    }

a[0] - копия
в foreach тоже копия. Значит, был не прав

а можно ли как-то использовать список структур без копирования? Или же для этого можно использовать только массивы?

Psilon · 19.10.2013, 23:38

IcyWind, даже при копировании структуры быстрее. А то что структуры копируются - это и есть свойство структур...

А структуры изменять нельзя, надеюсь вы это знаете.

@IcyWind · 20.10.2013, 00:14 **[ТС]**

Сообщение от Psilon

А структуры изменять нельзя, надеюсь вы это знаете.

я знаю не совсем то, на что вы надеетесь

1.) Структуры, находящиеся в коллекциях являются неизменяемыми
2.) В случаи нахождения структуры в массиве или в отдельной переменной, изменять поля структуры можно, но всегда нужно помнить, что по-умолчанию, структуры передаются копированием.
Лично я ещё не встречал ни одного случая, где бы потребовалось изменение структуры (уж очень я мало с ними работал). Но допускаю, что такие ситуации вполне могут иметь место

Psilon · 20.10.2013, 00:36

IcyWind,

Но допускаю, что такие ситуации вполне могут иметь место

не могут

http://sergeyteplyakov.blogspo... -post.html

ознакомьтесь

@IcyWind · 20.10.2013, 02:24 **[ТС]**

Открыл для себя:
-Все дело здесь в том, что согласно спецификации, при обращении к полю только для чтения вне конструктора, генерируется временная переменная, для которой и вызывается метод IncrementX
ох-хо-хох....а

C#
1
private readonly List<ComplexType>

на 20000 элементов, инициализированных в конструкторе, копирует 20000 ссылок?!

-Однако если рассматриваемый выше массив привести к одному из его интерфейсов, такому как IList<T>, то вся уличная магия в виде генерации особых IL-инструкций останутся за бортом, и мы получим поведение, описанное в начале этого раздела.

Добавлено через 1 час 14 минут

Сообщение от IcyWind

на 20000 элементов, инициализированных в конструкторе, копирует 20000 ссылок?!

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

к тому же уже и время позднее...
вопрос снимается))

Новые блоги и статьи Все статьи Все блоги /
Видеокарта простаивает ночами? Вот 4 проекта, которые загрузят её наукой Programma_Boinc 10.04.2026 Видеокарта простаивает ночами? Вот 4 проекта, которые загрузят её наукой Если на Windows стоит дискретная NVIDIA или AMD — можно отдать её вычислительную мощность реальным исследованиям. . . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .	модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .
Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ	Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .

@IcyWind 9 / 9 / 9 Регистрация: 19.09.2011 Сообщений: 272

	Использование Struct в сценариях для классов. Можно ли избежать boxing? 19.10.2013, 18:55. Показов 1336. Ответов 9 Метки нет (Все метки) Здравствуйте. Есть сценарий, для которого идеально подходят классы, а именно: -базовый класс с 5-7 наследниками. Эти классы содержат только поля. -полиморфный контейнер на основе базового класса -ну и, собственно, работа с полиморфным контейнером(в основном, на чтение и на linq запросы Any) Я знаю, что если в лоб заменить классы структурами, а базовый класс интерфейсом, то при моих сценариях (обращение к структуре через интерфейс) будет происходить boxing. сам вопрос: возможно ли как-то в данном сценарии заменить классы на структуры (с целью увеличения производительности), предотвратив при этом boxing при обращении к элементам полиморфного контейнера? 0

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	19.10.2013, 19:12
	IcyWind, разрешите вам ответить фотографией, лень шерстить файнридером: Миниатюры 1

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	19.10.2013, 19:14
	Так что ответ: при использовании полиморфизма избежать упаковки не получится. 0

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	19.10.2013, 23:38
	IcyWind, даже при копировании структуры быстрее. А то что структуры копируются - это и есть свойство структур... А структуры изменять нельзя, надеюсь вы это знаете. 0