Насколько плохо продолжать вызывать malloc() и free()?

В вашем примере ваша функция уже содержит системный вызов, поэтому относительная стоимость malloc/free будет практически неизмеримой. В моей системе цикл malloc/free туда и обратно занимает в среднем около 300 циклов, а самые дешевые системные вызовы (получение текущего времени, pid и т. д.) стоят не менее 2500 циклов. Ожидайте, что recv легко будет стоить в 10 раз дороже, и в этом случае стоимость выделения/освобождения памяти будет составлять не более 1% от общей стоимости этой операции.

Конечно, точное время будет варьироваться, но приблизительные порядки величины должны быть довольно постоянными в разных системах. Я бы даже не начал рассматривать удаление malloc/free в качестве оптимизации, за исключением функций, которые являются чисто пользовательскими. Где, вероятно, на самом деле более ценно обойтись без динамического выделения, так это в операциях, которые не должны иметь случаев сбоя. Здесь ценность заключается в том, что вы упрощаете и усложняете свой код, не прибегая к беспокоиться о том, что делать, когда malloc терпит неудачу.

Существуют накладные расходы, связанные с вызовом malloc и free. Блок должен быть выделен из кучи и помечен как используемый, когда вы освобождаетесь, происходит ревизия. Не зная, какую ОС или компилятор вы используете, это может быть в библиотеке c или на уровне управления памятью ОС. Поскольку вы выполняете много операций malloc и освобождаете, вы можете сильно фрагментировать свою кучу, где у вас может не хватить непрерывной свободной памяти для выполнения malloc в другом месте. Если вы можете выделить только один буфер и продолжать его повторно использовать, это, как правило, будет быстрее и с меньшей опасностью фрагментации кучи.

Я обнаружил, что malloc, realloc и free довольно дороги. Если вы можете избежать использования malloc, лучше повторно использовать память, которая у вас уже есть.

Изменить:
Похоже, я ошибаюсь в том, насколько дорогой malloc. Некоторые временные тесты с библиотекой GNU C версии 2.14 в Linux показывают, что для теста, который повторяется 100 000 раз и выделяет и освобождает 512 слотов со случайными размерами от 1 до 163840 байт:

tsc average loop = 408
tsc of longest loop = 294350

Так что тратить 408 циклов на malloc или new в тесном внутреннем цикле было бы глупо. В остальном не беспокойтесь об этом.

Маллок, как правило, довольно недорогой. Это дорого, только если он генерирует системный вызов, чтобы получить больше места в куче. Например, в UNIX-подобных системах в конечном итоге будет сгенерирован вызов sbrk, который будет дорогостоящим. Если вы неоднократно выполняете malloc и освобождаете память одного и того же размера, это будет происходить безумно быстро. Например, рассмотрим следующую небольшую тестовую программу:

#include <stdlib.h>


int main()
{
  int i=0;
  int *ptr;

  for(int i=0; i<1e6; i++) {
    ptr = malloc(1024*sizeof(int));
    free(ptr);
  }
}

Он выделяет 1024 целых числа и освобождает их, и делает это миллион раз. Запустив это на моем довольно скромном маленьком хромбуке, переделанном в Linux, я получаю такие тайминги:

time ./test

real    0m0.125s
user    0m0.122s
sys     0m0.003s

Теперь, если я закомментирую часть цикла malloc и free, я получу следующие тайминги:

time ./test

real    0m0.009s
user    0m0.005s
sys 0m0.005s

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

Это особенно быстро, если он может просто повторно использовать один и тот же кусок кучи снова и снова (как в данном случае). Конечно, если бы я продолжал постоянно выделять и увеличивать программу, это заняло бы больше времени, потому что это привело бы к нескольким системным вызовам.

Конечно, ваш пробег может варьироваться в зависимости от ОС, компилятора и реализации stdlib.

Вызов нескольких malloc/free может фактически увеличить объем памяти, используемой вашим процессом (без каких-либо утечек), если размер, передаваемый в malloc, является переменным, что подтверждается этим вопросом:

Использование памяти программы C - сообщается больше памяти, чем выделено

Таким образом, подход с одним буфером, вероятно, лучше.

Только тестирование может сказать. При программировании на C я ошибаюсь, избегая malloc, так как утечку памяти может быть довольно сложно исправить, если вы создадите ее случайно.

Измерьте производительность двух решений. Либо путем профилирования, либо измерения пропускной способности. Нельзя ничего сказать наверняка.