You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
perf(references): компактный индекс поиска вхождения по позиции
Вторичный индекс LocationRepository для findByPosition хранил
Map<URI, Map<Integer, Set<SymbolOccurrence>>> с отдельным
ConcurrentHashMap-множеством на каждую строку кода с вхождением. На больших
проектах это доминирующая статья расхода памяти индекса ссылок: на УПП
(~9500 модулей, 2.5M вхождений) — ~1.5M инстансов ConcurrentHashMap,
175 МБ таблиц Node[], ~4.6M boxed Integer; суммарно ~450 МБ.
Вместо карты «строка → множество» — ленивый отсортированный по началу
диапазона снимок вхождений документа (SymbolOccurrence[]) и бинарный поиск.
Диапазоны вхождений непересекающиеся, поэтому единственный кандидат —
вхождение с наибольшим началом диапазона, не превосходящим позицию. Снимок
сбрасывается при любом изменении вхождений URI и пересобирается при первом
следующем поиске; updateLocation больше не раскладывает вхождение по строкам.
Замер (analyze УПП, jcmd GC.class_histogram, live): инстансы CHM
1.52M → 14K, узлы CHM 10M → 5.9M, таблицы Node[] 175 → 43 МБ; SARIF-отчёт
эквивалентен базовому (идентичные счётчики правил), время анализа не выросло
(2:34 → 2:21).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
0 commit comments