LINUX.ORG.RU

Создание собственного диспетчера памяти для проектов C/C++

 


0

0

Оптимизация производительности программ является чрезвычайно важной задачей. Часто приходится сталкиваться с функциональными программами, написанными на C или C++, которые работают слишком медленно, потребляют слишком много памяти или, в худшем случае, делают и то и другое. Одним из важнейших средств, предоставляемых C/C++ разработчику для увеличения производительности и предотвращения утечек памяти, является управление выделением и перераспределением памяти. Это руководство проясняет принципы управления памятью на примере создания собственного диспетчера памяти для специальных случаев.

>>> Подробности

★★★

Проверено: Shaman007 ()
Ответ на: комментарий от the_coder

За таким - лучше к Мейерсу/Саттеру все-таки... А здесь - как на идиота. Начиная с того, что забыли сказать классическое "прежде чем оптимизировать, проверьте - а там ли узкое место". Местами просто чушь - например, что memory manager на каждый запрос о выделении берет память у ОС. Они давным-давно сами умеют пулы создавать. Основные тормоза не от этого, а от того, что стандартный менеджер поддерживает весьма сложные структуры для произвольного размера выделяемого блока, примитивный пример чего они и дают. Но кроме первого теста, они скромно не привели время выполнения программы. Подозреваю, что окончательный вариант не быстрее оригинальной реализации new...

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

Резюме - лучше б не писали совсем.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

IMHO достаточно хорошо это освещено у Александреску.

anonymous
()
Ответ на: комментарий от anonymous

>Местами просто чушь - например, что memory manager на каждый запрос о выделении берет память у ОС. Они давным-давно сами умеют пулы создавать.

+1

Интересно, в Линуксе приложение может отдать память системе? В Солярке память системе никогда не возвращается до завершения процесса. Это и правильно, для ядра процесс занимает непрерывную область памяти, если бы и можно было чего отдать то только уменьшить ее размер, фрагментации не предусмотрено. Возможно и есть какие экзотические исключения, но уж явно не из области new/delete.

A-234 ★★★★★
()
Ответ на: комментарий от A-234

> Интересно, в Линуксе приложение может отдать память системе?

brk(-size), munmap(), mremap()

anonymous
()
Ответ на: комментарий от A-234

>Местами просто чушь - например, что memory manager на каждый запрос о выделении берет память у ОС. Они давным-давно сами умеют пулы создавать.

Вообще-то не всегда. Если в кэше аллокатора нет соответствующего блока, то память берется через mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

anonymous
()
Ответ на: комментарий от A-234

>Это и правильно, для ядра процесс занимает непрерывную область памяти,

В "непрерывную область памяти" _задачи_ могут мапиться куски памяти откуда угодно, и необязательно памяти.

madcore ★★★★★
()
Ответ на: комментарий от madcore

>В "непрерывную область памяти" _задачи_ могут мапиться куски памяти откуда угодно, и необязательно памяти.

Во-первых какая разница какая память куда мапится? Во-вторых почувствуйте разницу между задачей - "task" и процессом - "process". И что у нас собственно scheduler переключает - задачи или процессы?

A-234 ★★★★★
()
Ответ на: комментарий от A-234

>Интересно, в Линуксе приложение может отдать память системе?

канэчно, как и в соляре (munmap например) однако зачем? ос все равно вытащит страницу у процесса из под носа, если clock алгоритм покажет, что она не используется.

>Это и правильно, для ядра процесс занимает непрерывную область памяти,

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

aydef
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.