Упрощенно нарежем типичную функцию на две части:

1. подготовительная/служебная работа: платим каждый вызов
2. полезная работа: то, ради чего тут собрались

Мы хотим, чтобы первая часть была максимально дешёвой относительно второй (кэп).

А вот что менее очевидно: объём полезной работы далеко не всегда линейно влияет на длительность функции.

———

Наглядный пример: системный вызов sendto, для отправки UDP-датаграмм.

Зависимость длительности вызова от размера payload на скрине.

Интересно, что при минимальном объеме данных в 1 байт (плюс заголовки), время работы внутри sendto ~1.8мкс.

Но если увеличить payload до 512 байт, длительность вырастает всего в 1.25x. И дальше с ростом, почти не меняется. 

(цифры на других системах могут отличаться, перепроверяйте)

Бо́льшая часть времени внутри sendto уходит не на сами данные, а на сопутствующую работу: оформить UDP/IP-заголовки, прогнать через сетевой стек, поставить в очередь на отправку.

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

———

И дело не в sendto. Так ведут себя многие вызовы, на которых всё держится: фикса доминирует, а объём данных почти не влияет.

Такое поведение трудно угадать без знания внутренней механики — но из этих деталей и складывается грамотный дизайн системы.

Поэтому не угадывай, замеряй.