Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает, цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.

Дисклеймер:

• Примеры кода нацелены на сохранение семантики. Подразумевается, что для внешнего пользователя способ работы с кодом не поменяется.

• Некоторые примеры могут не содержать оптимизации, о которых говорилось ранее. Это сделано намеренно, чтобы подчеркнуть именно ту оптимизацию, о которой говорится здесь и сейчас.

• Приведенные оптимизации не исправят проблемы производительности, связанные с неэффективной архитектурой или высокой асимптотической сложностью.

• Эффект от приведенных практик может быть незначительным в рамках небольшого участка кода. Заметных улучшений можно добиться только большом в масштабе.

• Будет много ассемблера (куда же без него?).

• Для получения результатов использовался clang 18.1 с флагами -std=c++20 -O3

Нет информации - нет оптимизаций

Рассмотрим простой пример. Мы написали функцию, которая на вход принимает две точки. Находим среднюю точку и, если обе ее координаты не равны нулю, возвращаем ее, иначе – точку с координатами (-1, -1). Код будет выглядеть примерно так:

#include "Point.hpp"
#include "GeometryAlgorithm.hpp"

Point GetSomePoint(Point p1, Point p2)
{
  Point p = Middle(p1, p2);

  return p.GetX() != 0 and p.GetY() != 0 ? p : Point{-1, -1};
}

Если вставить содержимое #include, то получим следующее:

class Point
{
private:
  double m_x;
  double m_y;

public:
  Point(double x, double y);

  double GetX() const;
  double GetY() const;
};

Point Middle(Point p1, Point p2);

Point GetSomePoint(Point p1, Point p2)
{
  Point p = Middle(p1, p2);

  return p.GetX() != 0 and p.GetY() != 0 
       ? p 
       : Point{-1, -1};
}

Именно так компилятор и будет видеть наш файл, препроцессор при виде директивы #include фактически просто копирует содержимое указанного файла. После компиляции (и дизассемблирования) в объектном файле будет следующий код:

.LCPI0_0:
  .quad 0xbff0000000000000
.LCPI0_1:
  .quad 0x0000000000000000
GetSomePoint(Point, Point):
  sub rsp, 40
  call Middle(Point, Point)@PLT
  movsd qword ptr [rsp], xmm0
  movsd qword ptr [rsp + 8], xmm1
  mov rdi, rsp
  call Point::GetX() const@PLT
  xorpd xmm1, xmm1
  ucomisd xmm0, xmm1
  jne .LBB0_1
  jnp .LBB0_3
.LBB0_1:
  mov rdi, rsp
  call Point::GetY() const@PLT
  ucomisd xmm0, qword ptr [rip + .LCPI0_1]
  jne .LBB0_2
  jnp .LBB0_3
.LBB0_2:
  movups xmm0, xmmword ptr [rsp]
  movaps xmmword ptr [rsp + 16], xmm0
  movsd xmm0, qword ptr [rsp + 16]
  movsd xmm1, qword ptr [rsp + 24]
  add rsp, 40
  ret
.LBB0_3:
  lea rdi, [rsp + 16]
  movsd xmm0, qword ptr [rip + .LCPI0_0]
  movaps xmm1, xmm0
  call Point::Point(double, double)@PLT
  movsd xmm0, qword ptr [rsp + 16]
  movsd xmm1, qword ptr [rsp + 24]
  add rsp, 40
  ret

В ассемблерном коде можно явно найти выделение памяти на стеке для промежуточного результата (переменная p), вызовы функций Point::GetX(), Point::GetY(), Middle и конструктора.

Уже стоит обратить внимание на то, что передача аргументов нашей функции в функцию Middle произошла бесплатно. И правда, перекладывать ничего не нужно, они уже находятся там, где должны. Давайте ради интереса усложним задачу и поменяем их местами:

Point GetSomePoint(Point p1, Point p2)
{
  Point p = Middle(p2, p1);

Тогда получим следующее:

.LCPI0_0:
  .quad 0xbff0000000000000
.LCPI0_1:
  .quad 0x0000000000000000
GetSomePoint(Point, Point):
  sub rsp, 40
  movaps xmm4, xmm1
  movaps xmm5, xmm0
  movapd xmm0, xmm2
  movapd xmm1, xmm3
  movaps xmm2, xmm5
  movaps xmm3, xmm4
  call Middle(Point, Point)@PLT
  movsd qword ptr [rsp], xmm0
  movsd qword ptr [rsp + 8], xmm1
  mov rdi, rsp
  call Point::GetX() const@PLT
  xorpd xmm1, xmm1
  ucomisd xmm0, xmm1
  jne .LBB0_1
  jnp .LBB0_3
.LBB0_1:
  mov rdi, rsp
  call Point::GetY() const@PLT
  ucomisd xmm0, qword ptr [rip + .LCPI0_1]
  jne .LBB0_2
  jnp .LBB0_3
.LBB0_2:
  movups xmm0, xmmword ptr [rsp]
  movaps xmmword ptr [rsp + 16], xmm0
  movsd xmm0, qword ptr [rsp + 16]
  movsd xmm1, qword ptr [rsp + 24]
  add rsp, 40
  ret
.LBB0_3:
  lea rdi, [rsp + 16]
  movsd xmm0, qword ptr [rip + .LCPI0_0]
  movaps xmm1, xmm0
  call Point::Point(double, double)@PLT
  movsd xmm0, qword ptr [rsp + 16]
  movsd xmm1, qword ptr [rsp + 24]
  add rsp, 40
  ret

Стало только хуже :D. Теперь можно и приступить к оптимизациям.

В реальном коде ситуация, когда аргументы функции сразу же передаются в другую функцию в неизменном виде, не так часто встречается. Поэтому в таком виде пример выглядит более правдоподобно.

Рассмотрим происходящее с точки зрения предметной области (пусть и скудной). Что делают функции GetX() и GetY() нам очевидно. То же касается и порядка аргументов функции Middle() – он не важен, так как результат останется такой же. Это очевидно нам, но не компилятору.

Довольно распространенная практика на языках С и С++ — разделять файлы на заголовочные и реализацию. В данном случае так и происходит. Реализация методов класса Point и функции Middle находятся в других файлах. В данной единице трансляции нет никакой информации о том, что эти функции делают. Это значительно ограничивает компилятор в оптимизациях.

Такой подход оправдан (я его не критикую), это как минимум полезно для скорости компиляции. Тем не менее, давайте попробуем дать компилятору информацию о тривиальных функциях. Для этого перенесем реализацию в заголовочный файл и добавим ключевое слово inline для соблюдения ODR — one definition rule. То же самое сделаем и для конструктора.

class Point
{
private:
  double m_x;
  double m_y;

public:
  inline Point(double x, double y)
    : m_x(x)
    , m_y(y)
  {}

  inline double GetX() const { return m_x; }
  inline double GetY() const { return m_y; }
};

Результат впечатляет:

.LCPI0_0:
  .quad 0xbff0000000000000
GetSomePoint(Point, Point):
  push rax
  movaps xmm4, xmm1
  movapd xmm5, xmm0
  movapd xmm0, xmm2
  movapd xmm1, xmm3
  movapd xmm2, xmm5
  movaps xmm3, xmm4
  call Middle(Point, Point)@PLT
  xorpd xmm2, xmm2
  movapd xmm3, xmm1
  cmpneqpd xmm3, xmm2
  cmpneqpd xmm2, xmm0
  andpd xmm2, xmm3
  movd eax, xmm2
  test al, 1
  jne .LBB0_2
  movsd xmm0, qword ptr [rip + .LCPI0_0]
  movapd xmm1, xmm0
.LBB0_2:
  pop rax
  ret

Не будем останавливаться и сделаем то же для функции `Middle`:

inline Point Middle(Point p1, Point p2)
{
  double x = p1.GetX() / 2 + p2.GetX() / 2;
  double y = p1.GetY() / 2 + p2.GetY() / 2;
  return Point{x, y};
}

Итого получаем следующее:

.LCPI0_0:
  .quad 0x3fe0000000000000
  .quad 0x3fe0000000000000
.LCPI0_1:
  .quad 0xbff0000000000000
  .quad 0xbff0000000000000
GetSomePoint(Point, Point):
  unpcklpd xmm2, xmm3
  movapd xmm3, xmmword ptr [rip + .LCPI0_0]
  mulpd xmm2, xmm3
  unpcklpd xmm0, xmm1
  mulpd xmm0, xmm3
  addpd xmm0, xmm2
  xorpd xmm1, xmm1
  movapd xmm2, xmm0
  cmpneqpd xmm2, xmm1
  movapd xmm3, xmm0
  unpckhpd xmm3, xmm0
  cmpneqpd xmm3, xmm1
  andpd xmm3, xmm2
  pshufd xmm2, xmm3, 68
  andpd xmm0, xmm2
  andnpd xmm2, xmmword ptr [rip + .LCPI0_1]
  orpd xmm2, xmm0
  pshufd xmm1, xmm2, 238
  movapd xmm0, xmm2
  ret

Результат стал не таким тривиальным, как был до этого. Но даже при беглом осмотре становится понятно, что работать это будет значительно быстрее. Главное, на что стоит обратить внимание, это прямое обращение к полям класса без вызова getter-ов.

Мы получили то, что хотели. Код теперь будет работать быстрее, при этом семантика полностью сохранена. Всю сложную работу сделал компилятор, а исходный вид нашей функции остался неизменным.

Point GetSomePoint(Point p1, Point p2)
{
  Point p = Middle(p2, p1);

  return p.GetX() != 0 and p.GetY() != 0 ? p : Point{-1, -1};
}

Стоит указать на некоторые важные вещи:

• В данном примере функции тривиальные, что позволяет получить улучшение производительности практически бесплатно. В реальности (к сожалению) это не всегда уместно, поскольку скорость компиляции пострадает многократно, а оптимизации будут незаметны.

• Link time optimization не рассматриваем специально, речь в статье идет именно о преобразовании исходного кода.

• Существует мнение, что inline расставлять не стоит, компилятор лучше знает, где его надо использовать. Это правда, но лишь отчасти. Компилятор и правда лучше знает, но фактически ключевое слово inline используется только для ODR. Большинство современных компиляторов его игнорируют (уже достаточно давно) и строят оптимизации по своим правилам.

virtual

Избитый всеми (и мной тоже) пример с фигурами. У нас есть фигура, и в очередной раз надо вычислять ее площадь. Будем смотреть только на квадрат.

class Figure
{
public:
  virtual ~Figure() = default;

  virtual double Area() const = 0;
};

class Square : public Figure
{
private:
  double m_size;

public:
  virtual double Area() const override { return m_size * m_size; }
};

Напишем элементарную функцию:

double CalculateSomeArea(const Square* s)
{
  return s != nullptr ? s->Area() * 2 : 0;
}

Получаем следующее:

CalculateSomeArea(Square const*):
  test rdi, rdi
  je .LBB0_1
  push rax
  mov rax, qword ptr [rdi]
  call qword ptr [rax + 16]
  addsd xmm0, xmm0
  add rsp, 8
  ret
.LBB0_1:
  xorps xmm0, xmm0
  ret

Стоит обратить внимание на:

call qword ptr [rax + 16]

Это вызов виртуальной функции. В данном случае нам не поможет inline, даже несмотря на то, что тип объекта мы знаем (аргумент функции — Square). Причина в том, что компилятор делает предположение, что может быть какой-то наследник класса Square, который эту функцию переопределяет.

Его нет и быть не может. Скажем об этом прямо:

class Square final : public Figure
//           ~~~~~

Если же есть, например, квадрат с именем, который не переопределяет метод `Area()`, то можно сделать замену `override -> final`:

virtual double Area() const final { return m_size * m_size; }

Оба способа дают одинаковый результат:

CalculateSomeArea(Square const*):
  test rdi, rdi
  je .LBB0_1
  movsd xmm0, qword ptr [rdi + 8]
  mulsd xmm0, xmm0
  addsd xmm0, xmm0
  ret
.LBB0_1:
  xorps xmm0, xmm0
  ret

За счет того, что компилятор знает содержимое функции, а сама функция не переопределена, ее содержимое раскрывается по месту вызова. Благодаря этому мы избегаем ненужных операций.

Отсюда получается довольно интересный эффект:

class Figure
{
public:
  virtual ~Figure() = default;

  virtual double Area() const = 0;
};

class Square : public Figure
{
private:
  double m_size;

public:
  Square(double size)
    : m_size(size)
  {
  }

  virtual double Area() const override 
  { 
    return m_size * m_size; 
  }
};

void SetSomeNumber(double);

inline double FigureArea(const Figure* f)
{
  return f != nullptr ? f->Area() : 0;
}

void SomeCode(double value)
{
  Square s(value);
  double num = FigureArea(&s);
  SetSomeNumber(num);
}

Весь код сверху превращается в это:

SomeCode(double):
  mulsd xmm0, xmm0
  jmp SetSomeNumber(double)@PLT

Красиво, не правда ли? Мы сохранили абстракции, но при этом получили максимально производительный код.

Может произойти что угодно

class Bar
{
private:
  int m_int;
  double m_double;

public:
  Bar();
  ~Bar();

  int foo() const;
};

int SomeCode()
{
  Bar bar;
  return bar.foo();
}

Обычный код. Есть какой-то класс, у него есть какой-то метод. Мы его вызываем. Сразу скажу, inline тут не причем. Давайте посмотрим, что может пойти не так:

SomeCode():
  push rbx
  sub rsp, 16
  mov rbx, rsp
  mov rdi, rbx
  call Bar::Bar()@PLT
  mov rdi, rbx
  call Bar::foo() const@PLT
  mov ebx, eax
  mov rdi, rsp
  call Bar::~Bar()@PLT
  mov eax, ebx
  add rsp, 16
  pop rbx
  ret
  mov rbx, rax
  mov rdi, rsp
  call Bar::~Bar()@PLT
  mov rdi, rbx
  call _Unwind_Resume@PLT

DW.ref.__gxx_personality_v0:
  .quad __gxx_personality_v0

Все было бы хорошо, если бы не одна деталь — код после ret. В нашем коде мы исключениями не пользуемся. Глазами разработчика, если ничего не намекает на исключения, их скорее всего нет. Со стороны компилятора — наоборот. Не написали явно, значит, исключения могут быть. По понятным причинам, компилятор обязан встроить дополнительный код для их обработки. Добавим то, чего не хватает – noexcept.

class Bar
{
  // ...
  Bar() noexcept;
  ~Bar();

  int foo() const noexcept;

И все встает на свои места:

SomeCode():
  push rbp
  push rbx
  sub rsp, 24
  lea rbx, [rsp + 8]
  mov rdi, rbx
  call Bar::Bar()@PLT
  mov rdi, rbx
  call Bar::foo() const@PLT
  mov ebp, eax
  mov rdi, rbx
  call Bar::~Bar()@PLT
  mov eax, ebp
  add rsp, 24
  pop rbx
  pop rbp
  ret

За счет этого мы не только избавились от ненужного кода, но и лучше оптимизировали тот, который нам нужен.

Говоря простыми словами, компилятор разделяет код на части. Если какая-то функция может бросить исключение, то код до нее и после разделяется на разные фрагменты, а оптимизации применяются к каждому фрагменту отдельно. В действительности все устроено значительно сложнее, но этого достаточно, чтобы передать общую идею — даже неиспользуемый код может сделать гадость.

Эксперименты

Все мы любим эксперименты. И чтобы не быть голословным, напишем код и проверим. Будем писать игру, а точнее ее малую часть. Есть игровое поле, представленное в виде ячеек. Ячеек бывает два вида — море и суша. Напишем:

// Position.hpp
#pragma once

#include <cstddef>
#include <functional>

class Position
{
public:
  Position(int x, int y);

  int GetX() const;
  int GetY() const;

  bool operator==(const Position&) const = default;
  bool operator!=(const Position&) const = default;

private:
  int m_x;
  int m_y;
};

namespace std {
  template <>
  struct hash<Position>
  {
    size_t operator()(const Position& pos) const
    {
      return (static_cast<size_t>(pos.GetX()) << 32) + static_cast<size_t>(pos.GetY());
    }
  };
} // namespace std

// Cell.hpp
#pragma once

enum class CellType
{
  Ground,
  Sea
};

class Cell
{
public:
  Cell(CellType type);

  CellType GetType() const;

private:
  CellType m_type;
};

// Map.hpp
#pragma once

#include <memory>
#include <vector>

class Cell;
class Position;

class Map
{
public:
  Map();

  std::shared_ptr<Cell> GetCellAt(const Position& pos) const;

  int GetWidth() const;
  int GetHeight() const;

private:
  std::vector<std::shared_ptr<Cell>> m_cells;
  int m_width;
  int m_height;
};

Что-то похожее на правду получилось. Ячейки специально разместил в виде указателей. Предполагаем, что это какой-то сложный объект, и по значению мы его хранить не можем. Реализацию методов выкладывать не вижу смысла – они тривиальные. Теперь напишем алгоритм. У нас на карте есть суша и море. Мы хотим написать следующую функцию:

Для определенной позиции вычисляем размер острова (количество ячеек земли), на котором расположена указанная позиция. Если позиция указывает на море, возвращаем 0.

В качестве основы для алгоритма используем что-то похожее на поиск в глубину. Чтобы избежать переполнения стека, рекурсию использовать не будем. Получается следующий код:

#include "cell.hpp"
#include "map.hpp"
#include "position.hpp"

int GetGroundAreaAt(const Map& map, const Position& initialPos)
{
  int result = 0;
  std::unordered_set<Position> visited;
  std::stack<Position> toVisit;

  toVisit.emplace(initialPos);

  while (not toVisit.empty())
  {
    Position pos = toVisit.top();
    toVisit.pop();

    if (pos.GetX() < 0 or pos.GetY() < 0 or pos.GetX() >= map.GetWidth() or pos.GetY() >= map.GetHeight())
    {
      continue;
    }

    auto insertRes = visited.insert(pos);
    if (not insertRes.second)
    {
      continue;
    }

    auto c = map.GetCellAt(pos);
    if (c->GetType() != CellType::Ground)
    {
      continue;
    }

    ++result;

    toVisit.emplace(pos.GetX() + 1, pos.GetY());
    toVisit.emplace(pos.GetX() - 1, pos.GetY());
    toVisit.emplace(pos.GetX(), pos.GetY() + 1);
    toVisit.emplace(pos.GetX(), pos.GetY() - 1);
  }

  return result;
}

Проверять будем на карте размером 1000х1000. Заполняем случайно, с шансом 70% будет земля, так мы получим огромные острова (и долгое время выполнения :D). При проверке будем вызывать функцию для 100 случайных позиций. Сид для генерации устанавливаем фиксированный – 0. В результате время выполнения составляет 10.3 секунды. Кстати, максимальная площадь острова составила 700183 клетки (материк с лужами, а не острова в море), что объясняет такое время выполнения.

Теперь переделаем все методы классов Cell, Position и Map, они будут inline. Работа очевидная и в примерах кода не нуждается. Результат порадовал, время выполнения стало 9.2 секунды.

Не так впечатляет, как снижение сложности алгоритма или выполнение в несколько потоков, но тоже приятно – 10% без особых усилий. Как и говорилось в начале, подход не дает большого преимущества, но изменения в коде тривиальные, мы не рискуем что-то сломать. Разумеется, представленный алгоритм далек от идеала, но наша цель состояла в том, чтобы ускорить его без изменений. Если изменить алгоритм, время выполнения, естественно, будет ниже, но преимущество от описанных оптимизаций никуда не денется.

Бонус - range vs for

В качестве бонуса хочется поговорить про новинку С++20 (новинке уже 4 года...) – ranges. Давайте посмотрим, как их видит компилятор. Для начала сравним обычные алгоритмы и их аналоги в namespace std::ranges

bool HasZero(const std::vector<int>& vi)
{
  return std::any_of(vi.begin(), 
                     vi.end(), 
                     [](int x) { return x == 0; });
}

Тривиально, а в результате получаем это:

HasZero(std::vector<int, std::allocator<int>> const&):
  mov rdx, qword ptr [rdi]
  mov rax, qword ptr [rdi + 8]
  mov rdi, rax
  sub rdi, rdx
  mov rsi, rdi
  sar rsi, 4
  test rsi, rsi
  jle .LBB0_8
  and rdi, -16
  mov rcx, rdi
  add rcx, rdx
  inc rsi
  add rdx, 8
.LBB0_2:
  cmp dword ptr [rdx - 8], 0
  je .LBB0_17
  cmp dword ptr [rdx - 4], 0
  je .LBB0_18
  cmp dword ptr [rdx], 0
  je .LBB0_16
  cmp dword ptr [rdx + 4], 0
  je .LBB0_19
  dec rsi
  add rdx, 16
  cmp rsi, 1
  jg .LBB0_2
  mov rdi, rax
  sub rdi, rcx
  sar rdi, 2
  cmp rdi, 1
  jne .LBB0_9
  jmp .LBB0_15
.LBB0_8:
  mov rcx, rdx
  sar rdi, 2
  cmp rdi, 1
  je .LBB0_15
.LBB0_9:
  cmp rdi, 2
  je .LBB0_13
  mov rdx, rax
  cmp rdi, 3
  jne .LBB0_16
  cmp dword ptr [rcx], 0
  je .LBB0_21
  add rcx, 4
.LBB0_13:
  cmp dword ptr [rcx], 0
  je .LBB0_21
  add rcx, 4
.LBB0_15:
  cmp dword ptr [rcx], 0
  cmovne rcx, rax
  mov rdx, rcx
.LBB0_16:
  cmp rdx, rax
  setne al
  ret
.LBB0_17:
  add rdx, -8
  cmp rdx, rax
  setne al
  ret
.LBB0_18:
  add rdx, -4
  cmp rdx, rax
  setne al
  ret
.LBB0_21:
  mov rdx, rcx
  cmp rdx, rax
  setne al
  ret
.LBB0_19:
  add rdx, 4
  cmp rdx, rax
  setne al
  ret

Выглядит не очень, попробуем аналог:

bool HasZero(const std::vector<int>& vi)
{
  return std::ranges::any_of(vi, [](int x) { return x == 0; });
}

HasZero(std::vector<int, std::allocator<int>> const&):
  mov rdx, qword ptr [rdi]
  mov rcx, qword ptr [rdi + 8]
  cmp rdx, rcx
  je .LBB0_1
  add rdx, 4
.LBB0_4:
  cmp dword ptr [rdx - 4], 0
  sete al
  je .LBB0_2
  lea rsi, [rdx + 4]
  cmp rdx, rcx
  mov rdx, rsi
  jne .LBB0_4
.LBB0_2:
  ret
.LBB0_1:
  xor eax, eax
  ret

Очевидно, где лучше. Посмотрим кое-что интересней:

int OddSum(const std::vector<int>& vi)
{
  int res = 0;

  auto&& range = vi 
               | std::views::filter([](int x) { return x % 2 == 0; });

  for (int i : range)
  {
    res += i;
  }

  return res;
}

Стоит сразу оговориться — accumulate я специально не использовал, важно показать влияние от применения фильтрации.

Посмотрим, что получилось:

OddSum(std::vector<int, std::allocator<int>> const&):
  mov rcx, qword ptr [rdi]
  mov rdx, qword ptr [rdi + 8]
  cmp rcx, rdx
  je .LBB0_4
.LBB0_1:
  test byte ptr [rcx], 1
  je .LBB0_4
  add rcx, 4
  cmp rcx, rdx
  jne .LBB0_1
  xor eax, eax
  ret
.LBB0_4:
  xor eax, eax
.LBB0_5:
  cmp rcx, rdx
  je .LBB0_9
  add eax, dword ptr [rcx]
.LBB0_8:
  add rcx, 4
  cmp rcx, rdx
  je .LBB0_9
  test byte ptr [rcx], 1
  jne .LBB0_8
  jmp .LBB0_5
.LBB0_9:
  ret

Прекрасный код. Ничего лишнего, именно то, что я и написал. "Доделали!" – сказал я себе, радуясь, что новинка не только удобная, но и работать будет быстро.

"Ага, ЩАС!". Поверили? В статье про оптимизации в коде нет хитростей? Давайте проверим старый добрый цикл for, его точно доделали:

int OddSum(const std::vector<int>& vi)
{
  int res = 0;

  for (int i : vi)
  {
    if (i % 2 == 0)
    {
      res += i;
    }
  }

  return res;
}

.LCPI0_0:
  .long 1
  .long 1
  .long 1
  .long 1
OddSum(std::vector<int, std::allocator<int>> const&):
  mov r8, qword ptr [rdi]
  mov rcx, qword ptr [rdi + 8]
  cmp r8, rcx
  je .LBB0_1
  mov rdi, rcx
  sub rdi, r8
  add rdi, -4
  xor edx, edx
  cmp rdi, 28
  jae .LBB0_5
  xor eax, eax
  mov rsi, r8
  jmp .LBB0_8
.LBB0_1:
  xor eax, eax
  ret
.LBB0_5:
  shr rdi, 2
  inc rdi
  mov r9, rdi
  and r9, -8
  lea rsi, [r8 + 4*r9]
  pxor xmm0, xmm0
  xor eax, eax
  movdqa xmm3, xmmword ptr [rip + .LCPI0_0]
  pxor xmm2, xmm2
  pxor xmm1, xmm1
.LBB0_6:
  movdqu xmm4, xmmword ptr [r8 + 4*rax]
  movdqu xmm5, xmmword ptr [r8 + 4*rax + 16]
  movdqa xmm6, xmm4
  pand xmm6, xmm3
  movdqa xmm7, xmm5
  pand xmm7, xmm3
  pcmpeqd xmm6, xmm0
  pand xmm6, xmm4
  paddd xmm2, xmm6
  pcmpeqd xmm7, xmm0
  pand xmm7, xmm5
  paddd xmm1, xmm7
  add rax, 8
  cmp r9, rax
  jne .LBB0_6
  paddd xmm1, xmm2
  pshufd xmm0, xmm1, 238
  paddd xmm0, xmm1
  pshufd xmm1, xmm0, 85
  paddd xmm1, xmm0
  movd eax, xmm1
  cmp rdi, r9
  je .LBB0_2
.LBB0_8:
  mov edi, dword ptr [rsi]
  test dil, 1
  cmovne edi, edx
  add eax, edi
  add rsi, 4
  cmp rsi, rcx
  jne .LBB0_8
.LBB0_2:
  ret

Выглядит страшно. Но этот код работает примерно в 12 раз быстрее за счет векторизации. Да, элементарный код будет лучше, мнимая красота того не стоит. Однако в защиту стоит сказать, где применение ranges реально может ускорить быстродействие:

inline auto Document::GetFiguresInRect(const Rect& rect) const
{
  return std::views::all(m_figures)
       | std::views::filter([&rect](const Figure* fig) { return fig->CollidesRect(rect); })
       | std::views::transform([](auto&& i) -> const Figure* { return i; });
}

Документ содержит фигуры. Нам нужен список фигур, которые попадают в прямоугольник. Такой подход как минимум позволит избежать создания нового списка, то есть выделения памяти, что очень удобно.

Примечание: из-за своей специфики подобный подход опасен висячими ссылками, применять с осторожностью. Берегите свои ноги!

Итоги

• Для простых функций применение inline может быть оправдано, например:

  • Тривиальные get/set

  • Простые функции

  • Не сложные вычисления

• Для оптимизации работы виртуальных функций inline не всегда достаточно. Тем не менее, поставить у класса-наследника final может помочь компилятору лучше оптимизировать.

• Если необходимо применить функцию STL на весь контейнер, есть смысл выбрать версию из namespace std::ranges.

• Использование std::views вместо цикла for может быть оправдано только в тех случаях, когда мы избегаем создания нового контейнера. В остальных случаях обычный цикл будет как минимум не хуже.

• Исключения достаточно хорошо оптимизированы, но не бесплатны. Если их нет и не будет — не лишним будет добавить noexcept.