на главнуюВсе эхи RU.UNIX.PROG
войти ?

Re: Эффективность менеджера памяти

От Valentin Nechayev (2:5020/400) к Vadim Guchenko

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


From: Valentin Nechayev <netch@segfault.kiev.ua>


>>> Vadim Guchenko wrote:

VG> А насколько быстро/медленно работает менеджер памяти? Интересует применительно к FreeBSD, если
VG> это имеет значение. Много где видел, что программисты больше всего стараются экономить на
VG> количестве вызовов malloc(), пытаясь каким-то образом прогнозировать, сколько еще памяти может
VG> понадобиться, и выделять ее с запасом. Hо так ли он медленно работает? Hапример, никого же не
VG> смущает, что для чтения файла длиной 100 мегабайт блоками по 16 килобайт нужно вызвать функцию
VG> read() 6400 раз. Почему бы на каждый вызов read() не выделять через malloc() и очередной блок
VG> памяти в 16 килобайт?

Вполне можно. malloc работает по крайней мере не медленнее read на
таких объёмах.

VG> Конкретный пример. Hужно прочитать большой файл блоками по 16 килобайт. Можно завести для этих
VG> целей один-два буфера размером 16 килобайт и по мере выбирания данных приложением из начала
VG> буфера, сдвигать оставшиеся данные в начало буфера, освобождая конец буфера для чтения новых
VG> данных из файла.

А зачем двигать данные? Hадо двигать указатели в буферах. А передавать
данные из нескольких буферов через writev().

VG> Или можно ничего не сдвигать, а просто перед каждой операцией чтения выделять
VG> новый буфер через malloc() и добавлять его в конец цепочки буферов, а старые буфера освобождать
VG> и удалять из начала цепочки по мере их опустошения. Т.е. какие операции будут более
VG> эффективными:

VG> 1) memcpy(16K); read(16K);
VG> 2) free(16K); malloc(16K); read(16K);
VG> ?

VG> А если размер буфера будет не 16K, а скажем 1M? Временная сложность memcpy() равна O(N), где N -
VG> размер блока. А у malloc()/free()?

Тоже O(N). И сравнимо не с memcpy, а с заливкой нулями (по крайней
мере в начале работы)


--netch--
--- ifmail v.2.15dev5.4
* Origin: Dark side of coredump (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.UNIX.PROG?msgid=<1187334506@segfault.kiev.ua>+72871fa6