Программист должен действительно заботиться о том, сколько и/или как часто объекты создаются в.NET?

Это одна из тех проблем, на которую действительно сложно дать окончательный ответ, который поможет вам. Файл. NET GC очень хорошо настраивается под потребности вашего приложения в памяти. Достаточно ли хорошо, что ваше приложение можно кодировать, не беспокоясь об управлении памятью? Я не знаю.

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

По большей части, однако, я бы сказал, что GC будет хорошо справляться с управлением все это для вас.

Я видел слишком много случаев, когда люди «оптимизируют» весь мусор в своем коде, не особо заботясь о том, насколько хорошо он написан или даже насколько хорошо работает. Я думаю, что первая мысль должна быть направлена ​​на то, чтобы код решал текущую бизнес-проблему. Код должен быть хорошо продуман, легко обслуживаемым и должным образом протестированным.

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

Случайный совет:

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

Другой метод, который вы можете использовать в C #, - это перейти на собственный C ++ для ключевых частей, которые не работают достаточно хорошо. .

У меня все время одна и та же мысль.

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

Если вы знаете об этом и всегда смотрите, я считаю, что вы можете писать неидеальный код. Если вы начали с .NET / Java и не имели опыта программирования на низком уровне, скорее всего, вы напишете очень оскорбительный и неэффективный код.

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

Несмотря на наличие сборщика мусора, плохой код остается плохим кодом. Поэтому я бы сказал, что да, как разработчик .Net, вы все равно должны заботиться о том, сколько объектов вы создаете, и, что более важно, писать оптимизированный код.

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

.NET Управление памятью очень хорошее, и возможность программно настроить GC, если вам это нужно, - это хорошо.

Мне нравится то, что вы можете создавать свои собственные методы Dispose для классов, наследуя от IDisposable и настраивая его под свои нужды. Это отлично подходит для обеспечения того, чтобы подключения к сетям / файлам / базам данных всегда были очищены и таким образом не протекали. Также существует беспокойство о том, что уборка будет слишком ранней.

Вы можете подумать о написании набора кэшей объектов. Вместо создания новых экземпляров вы можете где-нибудь хранить список доступных объектов. Это поможет вам избежать GC.

Я хотел бы быть «легендой программного обеспечения» и мог бы говорить об этом своим голосом и дыхание, но так как я не такой, я полагаюсь на SL в таких вещах.

Я предлагаю следующее сообщение в блоге Эндрю Хантера о .NET GC:

http: //www.simple-talk. com / dotnet /. net-framework /standing-garbage-collection-in-.net /

Я согласен со всем, что было сказано выше: сборщик мусора - отличный инструмент, но его не следует использовать в качестве костыля.

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

Я думаю, вы сами ответили на свой вопрос - если это станет проблемой, то да! Я не думаю, что это вопрос .Net против Java, это действительно вопрос «должны ли мы делать все возможное, чтобы избежать определенных типов работы». Если вам нужна более высокая производительность, чем у вас есть, и после некоторого профилирования вы обнаружите, что создание экземпляра объекта или сборка мусора занимает уйму времени, то самое время попробовать какой-нибудь необычный подход (например, упомянутый вами пул).