МСУСамое ценное в статье Ковача - это заключение.

https://msdn.microsoft.com/ru-ru/magazine/cc163491.aspx Заключение: В настоящей статье рассматриваются различные проблемы, которые возникают в приложениях .NET и могут стать причиной утечек памяти или чрезмерного потребления памяти. Конечно, .NET в большой мере избавляет от забот о памяти, но чтобы быть уверенными, что приложение работает правильно и эффективно, нужно внимательно следить за тем, как оно использует память. Тот факт, что приложение является управляемым, не означает, что нужно выбросить и забыть профессиональные навыки и накопленный опыт разработки и отладки программных систем, полностью положиться на сборщик мусора и ждать, что он сотворит чудеса . Разрабатывая и отлаживая приложение, нужно постоянно следить за значениями счетчиков, которые характеризуют эффективность использования памяти.


Так что, a_voronin, самое время для изучения .NET :)

Боюсь, что на .NET я программировал уже слишком долго с первой версии ещё. GC.Collect использовал в боевом коде, использовал не раз, знаю результат. То, что кто-то написал, что сборщик мусора не надо вызывать, это его личное мнение, которое я лично проигнорирую.

МСУa_voroninБоюсь, что на .NET я программировал уже слишком долго с первой версии ещё. GC.Collect использовал в боевом коде, использовал не раз, знаю результат. То, что кто-то написал, что сборщик мусора не надо вызывать, это его личное мнение, которое я лично проигнорирую.
Боюсь, что ты просто облажался и тебе откровенно стыдно это признать. Остальные сопли по поводу твоего "долголетнего опыта" оставлю без комментариев.

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

МСУчто в .NET якобы не могут быть утечек. Твой перформанс про

a_voroninУтечку на .NET? Вы батенька что-то попутали. Это не C++

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

Это оскорбление. С хамом больше общаться не буду.

МСУa_voroninЯ таких как ты на собеседованиях сразу заворачиваю.
Мне страшного представить проф пригодность компании, где человека с нулевыми знаниями по .NET допустили собеседовать разработчиков. Заверни лучше голову свою в ковёр, клоун

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

МСУa_voroninСначала ты придумал, что я что-то имел ввиду, потом сделал какие-то выводу о моём уровне, на основе того, что сам сообразил, теперь на основе этой своей выдумки хамишь. до свиданье господин воображалкин.
Я придумал, что в .NET не бывает утечек? Я придумал, что .NET это не C++? Я начал хамски поучать перечитать, как работает распределение памяти в .NET? Я тебе дал ссылку и аргументировал твою неправоту. О каких выдумках ты тут вещаешь?

Ну то, что распределение памяти на C++ и NET отличается ты, я надеюсь, отрицать не будешь. То, что память не подлежит сборке на .NET, пока на неё есть ссылка, ты тоже отрицать не будешь. То, что в MSDN есть пример использования GC.Collect ты тоже отрицать не будешь? https://msdn.microsoft.com/en-us/library/xe0c2357(v=vs.110).aspx

Теперь скажи мне, уважаемый разработчик, архитектор или кто ты. Вот ты лопатишь какие-то данные в цикле. Лопатишь долго. Читаешь файл, например, делаешь кучу операций со строками и записываешь в другой файл. Что будет происходить с памятью. Вот пройдёт 100000 витков этого цикла, а память накапливается. Тебе уже не нужны все эти строки и промежуточные значения, ты их записал в выходной файл. Но они висят в памяти. Как действовать? Какой тут сценарий без GC.Collect -- я внимательно послушаю?

Вот мнение, которое я лично поддерживаю.

http://stackoverflow.com/questions/233596/best-practice-for-forcing-garbage-collection-in-c-sharp

The best practise is to not force a garbage collection in most cases. (Every system I have worked on that had forced garbage collections, had underlining problems that if solved would have removed the need to forced the garbage collection, and speeded the system up greatly.)

There are a few cases when you know more about memory usage then the garbage collector does. This is unlikely to be true in a multi user application, or a service that is responding to more then one request at a time.

However in some batch type processing you do know more then the GC. E.g. consider an application that.

Is given a list of file names on the command line
Processes a single file then write the result out to a results file.
While processing the file, creates a lot of interlinked objects that can not be collected until the processing of the file have complete (e.g. a parse tree)
Does not keep match state between the files it has processed.
You may be able to make a case (after careful) testing that you should force a full garbage collection after you have process each file.

Another cases is a service that wakes up every few minutes to process some items, and does not keep any state while it’s asleep. Then forcing a full collection just before going to sleep may be worthwhile.

The only time I would consider forcing a collection is when I know that a lot of object had been created recently and very few objects are currently referenced.
I would rather have a garbage collection API when I could give it hints about this type of thing without having to force a GC my self.

See also "Rico Mariani's Performance Tidbits"

МСУВо-первых, откуда в цикле взялось накапливание? Ведь я могу читать ридером прямо из источника (соединение с БД, xml, http, порты, сокеты и так далее) мимо памяти. И сразу же свопить куда-то в базу. В результате, никакого оверхеда в виде накапливания. Память не засирается, процесс происходит чисто и без шума. Какой нахрен GC.Collect? С твоими архитектурами только кур смешить. И да, почитай, что такое no tracking фетч. Поможет.

Опять на личности переходишь и опять придумываешь то, чего нет.

Рассмотрим задачу, где данные не сохраняются как есть. Понятно, что из одного потока в другой направить, это не вопрос. Допустим надо не как есть сохранять, а что-то делать ещё с теми данными, которые иду по потоку. Считать, трансформировать. Но не накапливать.

Ситуация заключалась в том, что память приращивалась и приращивалась, хотя указатели на эти промежуточные объекты уже были сняты. Может быть сейчас .NET оптимизировали, но некоторое число лет назад это наблюдалось. Поэтому и требовался принудительный GC.Collect. Никакого проседания производительности, как многое кричат, не было. Но сборка мусора длилась до полсекунды. На фоне многоминутных обработок, это было ничто. И память освобождалась. То есть ситуация, когда неиспользуемые объекты зависали была и и без GC.Collect не освобождалась. Дело было ещё по IIS и на фоне другой нагрузки.

Вот и всё, что я хотел сказать.

ЕвгенийВskyANA Полезный комментарий, спасибо.
А то уже собирался читать топик :)
Тот редкий случай, когда МСУ полностью прав. Видимо затмение сказывается :)

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

И я не надо быть столь наивным, чтобы считать, что он всегда прав. Вот это тоже считаете бредом, например? 9372672

МСУДавай по теме, начальник. Прав или не прав, какая разница. Будь проще.

Да я-то попроще.
Поражает твоя мания "читать между строк", то есть вкладывать в слова смысл, которого в них нет. Вот интересно, где я сказал, что являюсь или был начальником?