с/c++ у максимально оптимизированного под конкретны

1. malloc и new пытаются быть всем в одном флаконе для всех программистов.. .
Они выделят вам несколько байтов ровно тем же способом, что и несколько мегабайтов. Они не имеют понятия о том, что это за данные, место для которых они вам выделяют и какой у данных будет цикл жизни. Иными словами, у них нет той более широкой картины, которая есть у программистов.

2.Относительно плохая производительность.. .
Выделение памяти при помощи стандартных библиотечных функций или операторов обычно требует звонков в ядро. Это может оказывать на производительность вашего приложения всякого рода неприятные побочные воздействия, включая очистку буферов ассоциативной трансляции, копирование блоков памяти, и т. д. Уже этой причины достаточно для того, чтоб использование динамического распределения памяти стало очень дорогим с точки зрения производительности. Стоимость операций free или delete в некоторых схемах выделения памяти также может быть высокой, так как во многих случаях делается много дополнительной работы для того, чтобы попытаться улучшить состояние кучи перед последующими размещениями. «Дополнительная работа» является довольно расплывчатым термином, но она может означать объединение блоков памяти, а в некоторых случаях может означать проход всего списка областей памяти, выделенной вашему приложению! Это точно не то, на что вы хотели бы быть тратить драгоценные циклы процессора, если есть возможность этого избежать!

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

4. Отслеживание динамически выделенной памяти может быть непростой задачей.. .
Вместе с динамическим выделением в подарок приходит неизбежный риск утечки памяти. Я уверен, что мы все знаем, что такое утечки памяти, но если нет, то почитайте тут. Большинство студий строят инфраструктуру поверх своих динамических размещений, чтобы отслеживать, какая память и где используется.

5. Плохая локальность ссылок.. .
В сущности, нет никакого способа узнать, где та память, которую вернёт вам malloc или new, будет находиться по отношению к другим областям памяти в вашем приложении. Это может привести к тому, что у нас будет больше дорогостоящих промахов в кеше, чем нам нужно, и мы в концов будем танцевать в памяти как на углях. Так какая же есть альтернатива? Цель этой заметки — дать вам информацию (и чуток кода! ) о нескольких различных альтернативах, которые можно использовать вместо malloc и new, дабы побороться с только что оглашёнными проблемами.

И, резюмируя:
при интенсивной работе с большим количеством небольших фрагментов памяти можно получить существенную экономию – выиграть в скорости в несколько тысяч раз

Менеджер памяти операционной системы, например в Windows, выделяет процессу динамическую память страницами по 4 КБ по мере необходимости и делает это, для всех без исключения процессов, одинаково медленно. Учитывайте это.