Вау, это классно (не сарказм). Естественно я говорил про относительно динамические данные, которые в начале объекта (и указатели на структуры там же), причем не все, что там чуть глубже под капотом даже клиента я не знаю. Так глубоко я не лазил, мой максимум - перехватить эндсцену и вызвать что-нибудь, поэтому взял с приличным запасом. Написал я изначальный пост к тому, что проблема как раз не в объемах данных, а в (вероятной) сложности синхронизации.
Поговорим о том, что аллокация десятков структур(не классов) довольно затратная операция? А если частота зашкаливает?
Можно и поговорить. Затратная? Спорно, но допустим. Пара системных вызовов, на каждый из которых уйдет ~30 тактов. Работа планировщика в POSIX подстраивается под частые вызовы brk/sbrk при куче последовательных запросов на одинаковые блоки памяти. Медленная ли относительно передачи данных по сети? Нет. (Что есть аллокация классов для меня малоизвестно, если честно, может быть инстансов, но там различий мало, можно cppconf по 17 стандарту посмотреть, там было интересное выступление по этому поводу).
По поводу примера: большинство подтверждений получения из него инкапсулировано в контроллер, обрабатывающий TCP-фреймы. Текущие ОС являются системами "мягкого реального времени". Да, это нихрена не гарантирует "честное" реальное время, но там промахов один на миллион. Никто и никогда не пишет вещи подобные примеру (ну если человек в здравом уме) для высоконагруженных сервисов, потому что оверхед дикий.