Первый шаг - профилировать код и убедиться, что вы точно понимаете, где находится узкое место. Люди часто плохо угадывают узкие места в коде, и вы можете быть удивлены полученными результатами. Вы можете просто настроить несколько частей этой процедуры самостоятельно и регулярно сбрасывать минимальную / среднюю / максимальную длительность. Вы хотите увидеть наихудший случай (макс.), И если средняя продолжительность увеличивается с течением времени.
Я сомневаюсь, что malloc займет любую значительную часть этих 2 мс на разумном микроконтроллере, способном работать Linux; Я бы сказал, что вам скорее всего не хватит памяти из-за фрагментации, чем из-за проблем с производительностью. Если у вас есть другие системные вызовы в вашей функции, они легко примут на порядок больше, чем malloc.
Но если malloc действительно проблема, в зависимости от того, насколько недолговечны ваши объекты, сколько памяти вы можете позволить себе потратить впустую, и насколько ваши потребности известны заранее, есть несколько подходов, которые вы можете использовать:
Распределение общего назначения (malloc из вашей стандартной библиотеки или любой другой сторонней реализации): наилучший подход, если у вас есть «более чем достаточно» ОЗУ, много недолговечных объектов и нет строгих требований к задержке
- PROS: работает для любой размер объекта из коробки, знакомый интерфейс, память распределяется динамически, нет необходимости «планировать заранее», если память не является проблемой
- CONS: небольшое снижение производительности во время выделения и / или освобождения, проблемы фрагментации памяти при выполнении большого количества выделений / освобождений объектов разных размеров, неудача выделения во время выполнения менее определена inisti c и не может быть легко устранено во время выполнения
Пул памяти : наилучший подход в большинстве случаев, когда память ограничена, требуется низкая задержка, и объект должен жить дольше, чем единичная область видимости
- PROS: время выделения / освобождения гарантируется равным
O(1) в любой разумной реализации, не страдает от фрагментации, легче планировать его размер заранее, неудача в распределении во время выполнения (вероятно) легче смягчить - CONS: работает для одного определенного c размера объекта - память не распределяется между другими частями программы, требует планирования для правильного размера пула или риска потенциальной растраты памяти
Объекты на основе стека (автоматизация c -дурации) : лучше для меньших, недолговечные объекты (единичная область видимости)
- PROS: выделение и освобождение осуществляется автоматически, позволяет оптимально использовать ОЗУ для срока службы объекта, тыс. грн. Это инструменты, которые иногда могут выполнить c анализ вашего кода и оценить размер стека
- CONS: объекты ограничены областью действия одного блока - не могут совместно использовать объекты между вызовами прерываний
Отдельные статически распределенные объекты : лучший подход для долгоживущих объектов
- PROS: никакого выделения вообще нет - все необходимые объекты существуют на протяжении всего жизненного цикла приложения , нет проблем с выделением / освобождением
- CONS: тратит память, если объекты должны быть недолговечными
Даже если вы решите go для памяти Объединяйте программы по всей программе, убедитесь, что вы добавили профилирование / инструментарий в свой код. А затем навсегда оставьте его там, чтобы увидеть, как со временем меняется производительность.