Подавление сборка "мусора" C#
Что-то похожее на этот ответ , что вам нужно.
Вы должны извлечь файл из архива особым образом.
BufferedReader input = new BufferedReader(new InputStreamReader(
this.getClass().getClassLoader().getResourceAsStream("1.txt")));
6 ответов
Если вы не подтвердите, что сборщик мусора активно замедляет работу вашего приложения, вам не следует предпринимать шаги, чтобы нанести ущерб функциональности вашей среды выполнения.
Судя по вашему вопросу, вы не подтвердили, что сборщик мусора является проблемой. Я сильно сомневаюсь, что это так.
Оптимизируйте только то, что нужно оптимизировать.
Вы можете остановить сборщик мусора от завершения любого из ваших объектов, используя статический метод:
GC.SuppressFinalize(*your object*)
Дополнительная информация здесь: текст ссылки
Посмотрите на свойство System.Runtime.GCSettings.LatencyMode .
Установка для свойства GCServer значения true в app.config также поможет сократить сборщик мусора ( в моем случае в 10 раз меньше GC при включении).
Это происходит (обычно) только тогда, когда сборщику мусора все равно нужна память Gen2 (поскольку gen1 заполнен). Вы задаетесь вопросом об этом умозрительно, или у вас действительно есть проблема с тем, что сборщик мусора занимает большую часть времени выполнения? Если у вас нет проблем, я предлагаю вам пока не беспокоиться об этом - но следите за ними с помощью мониторов производительности.
Это можно измерить с помощью монитора производительности. Откройте perfmon и добавьте счетчики производительности, связанные с памятью .NET CLR. Эти счетчики зависят от процесса, и с их помощью вы можете отслеживать количество коллекций и размеры различных поколений и, в частности, «% времени в GC». Вот текст объяснения этого счетчика:
% времени в GC - это процент от затраченное время, которое было потрачено в выполнение сборки мусора (GC) с последнего цикла сборки мусора. Этот счетчик обычно показатель работы сделано сборщиком мусора на от имени приложения для сбора и компактная память. Этот счетчик обновляется только в конце каждого сборщика мусора а значение счетчика отражает последнее наблюдаемое значение; это не в среднем.
Если вы наблюдаете за этими счетчиками во время работы своей программы, вы должны получить ответ для частоты и стоимости GC из-за ваших решений по памяти.
Здесь хорошее обсуждение различных счетчиков производительности GC . Кажется, что 10% - это нормально.
Мое приложение ASP.NET - система B2B - начиналось с 35-40 МБ, когда к нему заходил первый пользователь. По прошествии этих минут приложение увеличивалось до 180 МБ при переходе на страницы 2 или 3 пользователей. Прочитав передовой опыт разработки .net и руководство по производительности сборщика мусора, я обнаружил, что проблема заключалась в дизайне моего приложения. Я не сразу согласился.
Я был в ужасе от того, насколько легко мы можем делать ошибки. Я отказался от многих функций и начал упрощать некоторые объекты. Значение:
Избегайте смешивания большого количества страниц и интеллектуальных и коммуникативных пользовательских элементов управления (тех, которые обладают множеством функций, которые на самом деле больше всего существуют для каждой страницы, использующей этот элемент управления).
Прекратите создавать универсальные функции для базовых классов. Иногда предпочтительнее повторить. Наследование - это стоимость.
В отношении некоторых сложных функций я ставил все на одну и ту же функцию. ДА, максимум до 100 строк. Когда я прочитал эту рекомендацию по производительности .net, я не поверил ей, но она работает. Стеки вызовов - это проблема, использование свойств класса поверх локальных переменных - проблема. Переменные уровня класса могут быть адом…
Прекратите использовать сложные базовые классы, базовых классов с более чем 7 строками не должно быть. Если вы распределите большие классы по всему фреймворку, у вас возникнут проблемы.
Я начинаю использовать больше статических объектов и функций. Я видел приложение, которое разработал другой парень. Все методы объектов доступа к данным (вставка, обновление, удаление, выбор) были статическими. Приложение с большим количеством одновременных пользователей никогда не занимает больше 45 МБ.
Для сохранения некоторых проектов мне нравится шаблон устойчивого состояния. Я учился в реальном мире, но автор Нигард также согласен со мной в своей книге: Release IT - Design and Deploy Production-Ready software. Он называет такой подход моделью устойчивого состояния. Этот шаблон говорит, что нам может понадобиться что-то для освобождения простаивающих ресурсов.
Возможно, вы захотите поиграть с файлом конфигурации компьютера. В атрибуте memoryLimit вы укажете процент памяти, который может быть использован до перезапуска процесса.
Вы также можете захотеть поиграть с файлом конфигурации компьютера. По этому атрибуту GC будет определять поведение машины (GC рабочей станции и GC сервера). Эта опция также может кардинально изменить поведение потребления памяти.
Я добился большого успеха, когда начал заботиться об этих элементах. Надеюсь на эту помощь.
- ИЗМЕНЕНО 04-05-2014 будет указывать процент памяти, который может быть использован до перезапуска процесса.
Вы также можете захотеть поиграть с файлом конфигурации на компьютере. По этому атрибуту GC будет определять поведение машины (GC рабочей станции и GC сервера). Эта опция также может кардинально изменить поведение потребления памяти.
Я добился большого успеха, когда начал заботиться об этих элементах. Надеюсь на эту помощь.
- ИЗМЕНЕНО 04-05-2014 будет указывать процент памяти, который может быть использован до перезапуска процесса.
Вы также можете захотеть поиграть с файлом конфигурации на компьютере. По этому атрибуту GC будет определять поведение машины (GC рабочей станции и GC сервера). Эта опция также может кардинально изменить поведение потребления памяти.
Я добился большого успеха, когда начал заботиться об этих элементах. Надеюсь на эту помощь.
- ИЗМЕНЕНО 04-05-2014 Я изменил свое мнение о многих вещах из-за улучшений новых версий GC и достижений HTML 5 и MVC framework.