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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в glibc вроде как 4096