LINUX.ORG.RU

C и выделение памяти


0

0

Читал в интернете, что операции выделения и освобождения памяти (в данном случае, язык "С"; malloc() && free()) являются "дорогостоящими" и "медленными" для данного процесса (программы). Хотелось бы узнать при каких условиях они таковыми являются (или всегда)? И как это проявляется?

Был бы очень благодарен за линки на соответствующие материалы про оптимизацию (или здесь так же действует гениальное высказывание про "корень всех зол"?) таких программ.

Спасибо.

anonymous

Re: C и выделение памяти

> Читал в интернете, что операции выделения и освобождения памяти (в данном случае, язык "С"; malloc() && free()) являются "дорогостоящими" и "медленными" для данного процесса (программы).

бред. дорогостоящими и медленными по сравнению с чем?

> Хотелось бы узнать при каких условиях они таковыми являются (или всегда)? И как это проявляется?

1) выделение долгоживущих маленьких кусков памяти

2) частое выделение кратковременных маленьких кусков памяти

3) миксирование в программе выделения очень больших кусков памяти с очень маленькими.

всё про аллокаторы можно узнать тут(доп. ссылки там же):

http://gee.cs.oswego.edu/dl/html/malloc.html

asgard ()

Re: C и выделение памяти

Всегда являются. Проявляется в том, что это долгая и затратная операция. Если надо выделять маленький объём памяти, надо её выделять на стеке. Порой надо писать свои аллокаторы, но это уже крайняя мера.

anonymous ()

Re: C и выделение памяти

Если у тебя не идёт интенсивное выделение/освобождение памяти, то можешь смело использовать штатные malloc/free.

execve ()

Re: C и выделение памяти

>Читал в интернете, что операции выделения и освобождения памяти (в данном случае, язык "С"; malloc() && free()) являются "дорогостоящими" и "медленными" для данного процесса (программы).

че то за бред, да они медленные, но это сильно много от чего зависит.

Во первых от mm, во вторых от аллокатора libc.

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

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

malloc() может выделить память и вернуть адрес, а может не выделить память и вернуть адрес - поэтому ограничиватся ТОЛЬКО проверками на NULL нет смысла если писать что то серьезное и большое;

Да и язык Си тут ни причем - это ВЕЗДЕ выделение памяти будет длительной и не достаточно надежной операцией.

PS Стэк перегружать тоже не стоит, иначе его можно быстрее и проще засрать и при отладке наблюдать сорванный стэк и думать "эээ че то я та сделал то ?"

такие вот общие рекомендации.

alphex_kaanoken ★★★ ()
Ответ на: Re: C и выделение памяти от alphex_kaanoken

Re: C и выделение памяти

> malloc() может выделить память и вернуть адрес, а может не выделить память и вернуть адрес - поэтому ограничиватся ТОЛЬКО проверками на NULL нет смысла если писать что то серьезное и большое;

это кстати да: man malloc:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer. In case Linux is employed under circumstances where it would be less desirable to suddenly lose some randomly picked processes, and moreover the kernel version is sufficiently recent, one can switch off this overcommitting behavior using a command like # echo 2 > /proc/sys/vm/overcommit_memory See also the kernel Documentation directory, files vm/overcommit-accounting and sysctl/vm.txt.

> PS Стэк перегружать тоже не стоит, иначе его можно быстрее и проще засрать и при отладке наблюдать сорванный стэк и думать "эээ че то я та сделал то ?"

иногда просто без этого обойтись трудно.

asgard ()

Re: C и выделение памяти

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

anonymous ()
Ответ на: Re: C и выделение памяти от anonymous

Re: C и выделение памяти

> Спасибо за ответы. А каков критерий "маленьких кусков памяти", сколько байт уже считается "большим" в данном случае?

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

asgard ()
Ответ на: Re: C и выделение памяти от anonymous

Re: C и выделение памяти

>А каков критерий "маленьких кусков памяти", сколько байт уже считается "большим" в данном случае?

ну допустим выделить 128 байт, за ним выделить 4096 байт, потом те 128 освободить - в случае с glibc-ым аллокатором будет оч плохо.

собственно почему firefox так кушает много - именно поэтому.

alphex_kaanoken ★★★ ()
Ответ на: Re: C и выделение памяти от asgard

Re: C и выделение памяти

>зависит от алокатора. каждый алокатор определяет некоторый размер минимального куска памяти, N. если был запрошен кусок памяти < N, то он округлить до N. куски размера N считаются маленькими кусками, тк их частое выделение приведёт к операциям разбиения более крупных кусков из пула на более мелкие до достижения результата.

в glibc вроде как 4096

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