производительность — есть ли вызовы функций в C ++?

В моем проекте у меня есть класс, где время выполнения — первая цель. Из-за этого меня не волнует обслуживание, заказ и так далее. По крайней мере, мне было наплевать до вчерашнего дня … Теперь я нахожусь в ситуации, когда я тоже должен немного волноваться об этом.

У меня есть класс, скажем, A, который выполняет многократное сканирование изображений, поступающих с камеры, то есть окно с переменной шириной сканирует их в режиме реального времени.

class A{
// methods and attributes of A:
...
void runiterator(){
...
for{    // change window’s dimension
for{  // rows
for{ // columns
// many lines of code of operations to be executed for each window at each position
...
}
}
}
}
};

Производительность уже показывает небольшую задержку, но я мог бы ее решить, пропустив ограниченную область изображения. Кроме того, у меня есть вторая функция, скажем, B, которая имеет точно такую ​​же схему, что и A, и выполняет различные операции при каждом сканировании (и, к счастью, намного быстрее, чем A).

Что ж, теперь пришло время объединить все операции, чтобы значительно улучшить общий результат. Только то, что код станет действительно запутанным, огромным и смешивающим вещи, которые действительно отличаются. Я подумал определить класс X, который выполняет итерации и при каждом сканировании выполняет вызовы функций для одной функции в A_new и одной в B_new. Но я обеспокоен тем, что около 200000×2 вызовов функций на изображение может привести к снижению производительности.

Какой твой совет?

РЕДАКТИРОВАТЬ
С классом X, который вызывает только Anew (так что его можно сравнить только с тем, что сейчас есть A), я получаю в среднем много повторений:

Время выполнения X на серии из 56 изображений = 6,15 с
Время выполнения A на одной серии из 56 изображений = 5,98 с

Кажется, мои подозреваемые были не так наивны.
Разница составляет около 3%, не так много, но все же извините за потерю.

С __forceinline время для X равно 5,98 с, но я бы предпочел не полагаться на него.

Я думаю, что код оптимизирован и поля для дальнейших улучшений очень малы.
На самом деле он делает много вещей на изображениях за относительно короткое время.
Последовательная обработка данных в классе А невозможна, поскольку она основана на значениях, полученных на изображениях, которые непредсказуемы. Это причина, по которой класс B (которому это удается) намного быстрее.