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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gde by posmotret kak pisat svoi allokator?

> Gde by posmotret kak pisat svoi allokator?

Попробуй K&R для начала - разделы 5.4 и 8.7

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

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

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

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

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

> Gde by posmotret kak pisat svoi allokator?

как советовали выше - k&r, а потом вкуривать реализацию doug's lea allocator

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

в glibc вроде как 4096

gde to ya uzhe slyshal chto doug's lea allocator uzhe integrirovan v tekushie versii glibc...

dlmalloc()