[performance] Ground cache после 300k колонок полностью сканируется на каждом ответе #31

New Issue

2026-10-29T12:25:03Z

chexit commented

2026-10-29 12:25:03 +00:00

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

Ground::answer при known.len()>300000 вызывает HashMap::retain по всем колонкам. Если все записи ещё моложе 2000 тиков, ничего не удаляется; следующий ответ снова запускает полный scan. Порог 300k — триггер очистки, а не строгий лимит памяти, вопреки дополнительному ревью.

Проверено оригинальным Ground в native release: заполнить 300001 свежую колонку на now=100; затем 25 раз добавить по одной на now=101. Cache вырос до 300026, при каждом answer выполняется retain по всей таблице. Около 0.55 мс на answer на этой машине, не WASM benchmark. При реальном темпе 20 Гц и крупном кэше это лишняя работа; внутри WASM размер памяти также стоит контролировать (#9).

Предложение: планировать full cleanup с ограниченной частотой/после следующего порога либо чистить инкрементально с бюджетом. Если нужен строгий memory budget — определить политику eviction отдельно и согласовать с приоритетом первичных ground queries (#1), чтобы экономия памяти не делала рельеф систематически невидимым.

Критерий: поток свежих ответов после порога не вызывает полный scan каждый тик; stale записи удаляются; память и максимальное время tick контролируются.

Код:

		airdef/airdef-mod/src/sim/mod.rs
		Line 198 in 90379f6
	
				    pub fn answer(&mut self, answers: Vec<(i32, i32, i32)>, now: u64) {

.

Проверено на опубликованном `90379f6` при проверке дополнительного ревью. Незакоммиченные изменения из чужой рабочей копии недоступны. Ground::answer при known.len()>300000 вызывает HashMap::retain по всем колонкам. Если все записи ещё моложе 2000 тиков, ничего не удаляется; следующий ответ снова запускает полный scan. Порог 300k — триггер очистки, а не строгий лимит памяти, вопреки дополнительному ревью. Проверено оригинальным Ground в native release: заполнить 300001 свежую колонку на now=100; затем 25 раз добавить по одной на now=101. Cache вырос до 300026, при каждом answer выполняется retain по всей таблице. Около 0.55 мс на answer на этой машине, не WASM benchmark. При реальном темпе 20 Гц и крупном кэше это лишняя работа; внутри WASM размер памяти также стоит контролировать (#9). Предложение: планировать full cleanup с ограниченной частотой/после следующего порога либо чистить инкрементально с бюджетом. Если нужен строгий memory budget — определить политику eviction отдельно и согласовать с приоритетом первичных ground queries (#1), чтобы экономия памяти не делала рельеф систематически невидимым. Критерий: поток свежих ответов после порога не вызывает полный scan каждый тик; stale записи удаляются; память и максимальное время tick контролируются. Код: https://gitea.maoniao.team/chexit/airdef/src/commit/90379f6/airdef-mod/src/sim/mod.rs#L198.