Это занимает время для освобождения памяти?

По моему опыту, вызовы для освобождения или удаления не должны занимать много времени. Тем не менее, я видел множество случаев, когда для разрушения объектов действительно требуется нетривиальное время из-за деструкторов, которые делали нетривиальные вещи. Если вы не можете сказать, что занимает время во время разрушения, используйте отладчик и / или профилировщик, чтобы определить, что происходит. Если профилировщик показывает, что на самом деле вызовы free () занимают много времени, вам следует улучшить схему распределения памяти, потому что вы должны создавать чрезвычайно большое количество небольших объектов.

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

Вы можете избежать вызова free для объекта, используя вызов деструктора my_object-> ~ my_class () вместо delete my_object . Вы можете избежать free для всех объектов класса, переопределив и аннулировав оператор delete (void *) {} внутри класса. Производные классы с виртуальными деструкторами унаследуют этот delete , в противном случае вы можете скопировать-вставить (или, возможно, , используя base :: operator delete; ).

Это намного чище, чем вызов exit . Только убедитесь, что вам не нужно возвращать эту память!

Я не могу себе представить, как вы бы использовали достаточно памяти, чтобы это имело значение, но одним из способов, которым я ускорил программу, было использование boost :: object_pool для выделения памяти для двоичного дерева. Основным преимуществом для меня было то, что я мог просто поместить пул объектов в качестве переменной-члена дерева, и когда дерево выходило за пределы области видимости или было удалено, пул объектов удалялся сразу (что позволяло мне не использовать рекурсивный деконструктор для узлов). object_pool действительно вызывает деконтрукторы всех своих объектов при выходе. Я не уверен, обрабатывает ли он пустые деконтракторы особым образом или нет.

Если вам не нужен ваш распределитель для вызова конструктора, вы также можете использовать boost :: pool , который, я думаю, может освободить место быстрее, потому что ему вообще не нужно вызывать деконструкторы, а просто удалил кусок памяти в одном free () .

время, вероятно, тратится не на освобождение памяти, а на вызов всех деструкторов. Вы можете предоставить свой собственный распределитель, который не вызывает деструктор (если объект на карте не нужно разрушать, а только освобождать).

Также обратите внимание на другой вопрос: Распределители, соответствующие STL C ++

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

Да, освобождение памяти может занять некоторое время, а также, возможно, у вас есть код, выполняющийся как вызываемые деструкторы. Photoshop не использует 3-8 ГБ памяти.

Также вам, возможно, следует добавить в приложение профилирование, чтобы убедиться, что это освобождение памяти, а не что-то еще.

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

Дело в том, что когда вы освобождаете память, обычно она фактически не возвращается в ОС - она ​​хранится в списке для перераспределения, и это, очевидно, медленно. Однако, если вы завершите процесс, ОС сразу же освободит всю вашу память, что должно быть значительно быстрее. Однако, как говорили другие, если у вас есть какие-либо деструкторы, которые необходимо запустить, вы должны убедиться, что они запускаются до принудительного вызова exit () или ExitProcess или любой такой функции.

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

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

Объекты в памяти организованы в куче. Они не удаляются сразу, они удаляются по одному, а стоимость удаления объекта составляет O (log n). Чтобы их освободить, нужно много времени.

Тогда ответ: да, это занимает так много времени.

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

ищут глобальные объекты и исследуют их деструкторы.

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

Это может быть перераспределение, но это просто дикая догадка. Что делают ваши деструкторы? Может быть, листает как сумасшедший. Тот факт, что ваше приложение выделяет X объема памяти, не означает, что оно его получит. Скорее всего, это будет подкачка виртуальной памяти. В зависимости от специфики вашего приложения и ОС, у вас может быть много страниц с ошибками.

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

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

Запустите vmstat и iostat, как только получите сообщение «конец», и ищите любые признаки того, что ввод-вывод идет как банан.

Для освобождения памяти может потребоваться время - структуры данных обновляются. Сколько времени зависит от используемого распределителя.

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

2 минуты звучат как много времени - возможно, вы захотите выполнить код очистки в отладчике (или использовать профилировщик, если это удобнее), чтобы увидеть, что на самом деле занимает все время.

(Я начал это как ответ на ndim, но получилось слишком долго)

Как ndim уже писал, завершение может занять много времени.
Вероятные причины:

• у вас много распределений, и части кучи выгружены на диск.
• длительно выполняющиеся деструкторы
• другие процедуры atexit
• Очистка, специфичная для ОС, например, уведомление DLL о завершении потока и процесса в Windows (не знаю, что именно происходит в Linux).

exit здесь не наихудший обходной путь, однако реальное поведение зависит от системы. например exit в WIndows / MSVC CRT запустит процедуры глобальных деструкторов / atexit , а затем вызовет ExitProcess, который закрывает дескрипторы (но не обязательно сбрасывает их - по крайней мере, это не гарантируется).

Недостатки: деструкторы объектов, выделенных кучей, не запускаются - если вы полагаетесь на них (например, для сохранения состояния), вы - тост. Кроме того, становится намного сложнее отслеживать реальные утечки памяти.

Найдите причину Вы должны сначала проанализировать происходящее.

например. Освободив вручную корневые объекты, которые все еще выделены, вы можете отделить время освобождения от очистки других процессов. Согласно вашему описанию, вероятная причина - память, но не единственная. Также возможна некоторая взаимоблокировка кода очистки до того, как он достигнет тайм-аута. Статистика мониторинга (например, ЦП / активность подкачки / использование диска) может дать подсказки.

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

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

Конечно, это возможно.

Около 7 лет назад у меня была аналогичная проблема в проекте, там было намного меньше памяти, но компьютеры тоже, я полагаю, работали медленнее.

В конце концов, нам пришлось бесплатно взглянуть на язык сборки, чтобы понять, почему он такой медленный, и казалось, что он по существу хранит освобожденные блоки в связанном списке, чтобы их можно было перераспределить, а также сканировал этот список ищу блоки для объединения. Сканирование списка было операцией O (n), но освобождение n объектов превратило его в O (n ^ 2)

. Наши тестовые данные заняли около 5 секунд, чтобы освободить память, но у некоторых клиентов было примерно в 10 раз больше данных, чем мы все использовали, и на завершение работы программы в их системах уходило 5-10 минут.

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

Возможно, у вас есть более разумная бесплатная функция, которая была у нас несколько лет назад, но я просто хотел сообщить, что это вполне возможно, если у вас есть много объектов, которые нужно освободить, и O (n) свободная операция.