Еще несколько вопросов о производительности и оптимизации ... (Локальные и классовые переменные и итерационные и рекурсивные операции вставки / поиска в дереве)

Question

Спокойной ночи,

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

1) Может ли быть выгодно с точки зрения производительности объявлять «рабочие переменные» функций, вызываемых несколько сотен раз, как (частные) переменные класса вместо того, чтобы создавать их экземпляры при каждом вызове (чтобы избежать нескольких ненужных выделений и, как следствие, нехватки памяти и т. Д. GC exections)? Имеет ли это какое-то значение с точки зрения производительности?

2) Есть ли существенный прирост производительности при вставке / поиске дерева кодирования с использованием итеративных функций вместо рекурсивных? В этом конкретном случае поиск может занять до 160000 рекурсивных вызовов, столько же, сколько узлов дерева (как и вставки), поэтому я подумал о реализации этих функций как итеративных, а не рекурсивных.

Большое спасибо.

Answer 1

1) Переменные не являются сборщиком мусора.Объекты есть.Всегда объявляйте свои переменные в правильной области.Используйте профилировщик, чтобы найти узкие места и оценить оптимизации перед их применением.Не преждевременно отказывайтесь от ремонтопригодности для скорости.

2) Вероятно.Используйте профилировщик.

Answer 2

1) может быть выгодно объявить ваши рабочие объекты как переменные частного класса, но не так часто, как вы думаете.Есть несколько вещей, которые вы должны рассмотреть.

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

Часто оказывается, что повторное использование объекта обходится дороже, чем выделение нового.Например, очистка Hashset или List часто намного дороже, чем выделение нового, и сборщик мусора может позаботиться о том, чтобы избавиться от него, когда вы закончите."пока экземпляр класса находится в области видимости.Это может быть проблемой, если вы забудете очистить его (т. Е. Установить null или очистить коллекцию), поскольку все, на что ссылаются частные переменные, не будет собираться мусором.Такое использование закрытых переменных исключает большую часть преимуществ, которые вы получаете, имея сборщик мусора.

Диспетчер памяти .NET очень хорошо оптимизирован для недолговечных объектов.Я обнаружил очень мало ситуаций, в которых имеет смысл выдвигать объект уровня метода в область видимости класса, чтобы избежать выделения памяти и издержек сборщика мусора.

Я повторю совет, данный @dtb: используйте профилировщик, чтобы найти узкие места и определить потенциальные возможности оптимизации.В противном случае вы просто ковыряетесь в темноте, и ваша «оптимизация», скорее всего, негативно скажется на производительности.