[performance] Индексировать треки и назначения целей вместо вложенных линейных поисков #26

New Issue

2026-10-29T12:24:29Z

chexit commented

2026-10-29 12:24:29 +00:00

Проверено на опубликованном 90379f6 при проверке дополнительного ревью. Незакоммиченные изменения из чужой рабочей копии недоступны.

update_sight объединяет tracks соседних РЛС через seen.contains для каждого ID; в плотной сети верхняя оценка O(STD²). В step_sams claimed/guns_on сканируют все установки для каждого кандидата. Линейные find(id) повторяются между ракетами и дронами; seen/own клонируются на каждую установку.

Замер изолированного native release (не WASM и не Mac): 61 S400 в одной точке, 65 видимых Шахедов, 25 update_sight → около 0.995 мс/вызов на этой машине. Это специальная плотная сцена; не доказывает, что update_sight — главный bottleneck реальной игры. «15 млн операций» из чужого ревью — теоретическая оценка, не измеренное число операций CPU.

Предложение: deterministic union через bitset/epoch marks или set с отдельно сохраняемым стабильным порядком; ID→index для активных дронов/установок; один раз за тик собрать счётчики reservations/guns_on. При swap_remove обязательно обновлять индекс перемещённого объекта; не менять tie-break и результаты из-за рандомного порядка HashMap. Внешние команды/смерти тоже должны поддерживать индексы.

Критерий: тот же seed даёт тот же trace; тесты удаления/одновременного пуска/потери трека проходят; native и WASM профили показывают эффект на малых и больших сценах. Связано с #8/#9.

Код:

		airdef/airdef-mod/src/sim/sight.rs
		Line 121 in 90379f6
	
				        let tracks: Vec<(DVec3, Vec<u32>)> =

,

		airdef/airdef-mod/src/sim/mod.rs
		Line 1740 in 90379f6
	
				            let claimed = |d: &Drone| {

.

Проверено на опубликованном `90379f6` при проверке дополнительного ревью. Незакоммиченные изменения из чужой рабочей копии недоступны. update_sight объединяет tracks соседних РЛС через seen.contains для каждого ID; в плотной сети верхняя оценка O(S*T*D²). В step_sams claimed/guns_on сканируют все установки для каждого кандидата. Линейные find(id) повторяются между ракетами и дронами; seen/own клонируются на каждую установку. Замер изолированного native release (не WASM и не Mac): 61 S400 в одной точке, 65 видимых Шахедов, 25 update_sight → около 0.995 мс/вызов на этой машине. Это специальная плотная сцена; не доказывает, что update_sight — главный bottleneck реальной игры. «15 млн операций» из чужого ревью — теоретическая оценка, не измеренное число операций CPU. Предложение: deterministic union через bitset/epoch marks или set с отдельно сохраняемым стабильным порядком; ID→index для активных дронов/установок; один раз за тик собрать счётчики reservations/guns_on. При swap_remove обязательно обновлять индекс перемещённого объекта; не менять tie-break и результаты из-за рандомного порядка HashMap. Внешние команды/смерти тоже должны поддерживать индексы. Критерий: тот же seed даёт тот же trace; тесты удаления/одновременного пуска/потери трека проходят; native и WASM профили показывают эффект на малых и больших сценах. Связано с #8/#9. Код: https://gitea.maoniao.team/chexit/airdef/src/commit/90379f6/airdef-mod/src/sim/sight.rs#L121, https://gitea.maoniao.team/chexit/airdef/src/commit/90379f6/airdef-mod/src/sim/mod.rs#L1740.

chexit commented

2026-10-29 12:26:11 +00:00

Дополнение: sim.lit также может содержать один ID от нескольких осветительных ракет/прожекторов; повторный contains не меняет результат, но добавляет работу. Можно включить lit в общий epoch/bitset подход после профилирования. Не выдавать наличие дубликатов или пересборку HUD каждый тик сами по себе за доказанный bottleneck.