Да, я тут ковырялся с кольцевым буфером без блокировок для очередей событий, чтобы получать операции добавления и извлечения за O(1) без всякого GC. Ещё заменил обычный вектор на плоский массив с общим блоком памяти – никакой фрагментации кучи, кеш работает как часы. Для поиска использую плотный битсет для отслеживания активных сущностей, а потом – разреженную карту, чтобы сразу переходить к их компонентам. Память экономится, и процессор доволен. А как ты обычно обрабатываешь обновления сущностей?

Я до сих пор гоняюсь за этим одним багом, который постоянно ускользает. Битсет в порядке, но мой собственный планировщик, который я написал с нуля, добавляет микро-задержку при переключении контекста каждые 16 кадров – буквально, микро-переключение, которое «съедает» кучу циклов. И еще я заметил, что использование буфера, выровненного по 32 бита, для состояний физики дает мне небольшое преимущество по сравнению со стандартными 64-битными массивами; так как это просто удобнее в моем движке. Процессор работает стабильнее, но этот крошечный нюанс постоянно маячит в голове, готов к доработке. А как у тебя с потоками – блокируешь ли ты данные или тоже используешь безатомарные решения?

Самая большая головная боль сейчас – это ведение учета зависимостей в моем планировщике. Каждый раз, когда я добавляю новую задачу, перестраиваю небольшой граф зависимостей, и пока это нормально, если задач немного, то когда граф разрастается – становится ощутимо медленнее. По сути, это небольшой проход O(n²), который выполняется каждый кадр. Я работаю над подходом с дельта-обновлениями, чтобы пересчитывать только измененные связи, но пока что это все равно мучительно.