Мое предложение было бы сохранить то, что у вас есть.
- Он уже разработан.
- Проверено.
- Интуитивно понятный / читаемый без использования макроса.
- Это расширяемое.
- Узких мест количественно не выявлено.
Иногда попытки оптимизировать, когда нет проблем, могут снизить производительность. Делали ли вы какие-либо тесты против теории своих друзей?
malloc
Большой кусок требует размещения смежного адресного пространства и может даже привести к сбою malloc
при успешном выполнении текущего метода ( фрагментация адресного пространства и т. Д.).
Когда я сказал, что ваша текущая реализация расширяема, я имею в виду, что изменение размера тривиально. Если вы выделите [100] [3] и позже поймете, что вам нужно [100] [4], то все, что вам нужно сделать, это 100 очень маленьких перераспределителей, вероятно, не меняющих адреса. Однако, если макро-метод требует изменения размера, вам нужно realloc
весь кусок, который может не существовать непрерывно. Что еще хуже, данные больше не находятся в нужном месте для доступа к макросу, потому что математика изменилась, поэтому вам понадобится серия дорогих memmove
s.
Обобщая, я думаю, что важно всегда кодировать с удобочитаемостью, удобством обслуживания и простотой использования - и оптимизировать его только после создания узкого места.