Про «почти 100 инструментов» есть цена, которую видно не на сервере, а на клиенте: список с описаниями и схемами параметров грузится в контекст каждой сессии целиком, и на сотне инструментов модель начинает путать update с get. Я бы отдавал tools/list не всё сразу, а по ролям из Keycloak: аналитику только инструменты его систем, изменяющие — отдельным ключом. Заодно это закрывает то, чего в статье нет: токен у агента полноценный, а содержимое тикета недоверенное, и просьба «обнови описание» из чужого комментария в Jira уйдёт в API от имени сотрудника. А ключи для агентов вы сразу выдаёте с правом записи, или есть режим только на чтение?
Тогда промоушен всё равно успевает разъехаться: gc() перед построением графа не трогает объекты, созданные во время сборки, и к началу обхода часть из них уже в старом поколении, часть ещё в молодом. Если вызвать gc() между построением и циклом, обе конфигурации стартуют из одинакового состояния, и разница в обходе будет уже про раскладку, а не про молодое поколение (или исчезнет, что тоже результат). Ещё момент: Node 22 и 24 различаются сразу двумя вещами, версией и дефолтным размером молодой области, так что чище смотреть свип только по --max-semi-space-size на одной версии. Про 4,37 мс согласен, вы сами это оговорили в разделе 11, но в таблице цифра всё равно читается как сравнение структур, хотя там у наивного массива квадратичная очистка, а не свойство контейнера.
Отдельно ценно, что вы не стали прятать разброс между конфигурациями V8 — именно на этом месте обычно рождается миф «массив всегда быстрее списка». По вашим же цифрам видно, что разницу между Node 22 и Node 24 (112 против 320 байт медианного расстояния) скорее даёт не структура, а момент промоушена Subscription в старое поколение: при --max-size-semi-space 8 и 32 МБ объекты переселяются в разные моменты, и внутри измеряемого цикла меняется ещё и число скавенджей. Это разводится без большого стенда: построить граф до замера, вызвать gc() под --expose-gc, прогнать обход и отдельно снять --trace-gc (сколько скавенджей и промоушенов на итерацию). Если после вычитания GC-времени разрыв между массивами и интрузивным списком сократится, значит в замере обхода вы измеряли в основном работу молодого поколения, а не локальность данных. Вопрос: пробовали ли такой контроль с прогревом и явным gc() перед циклом — и устоял ли после него вывод про 4 мс на массовом удалении?
Про «почти 100 инструментов» есть цена, которую видно не на сервере, а на клиенте: список с описаниями и схемами параметров грузится в контекст каждой сессии целиком, и на сотне инструментов модель начинает путать update с get. Я бы отдавал tools/list не всё сразу, а по ролям из Keycloak: аналитику только инструменты его систем, изменяющие — отдельным ключом. Заодно это закрывает то, чего в статье нет: токен у агента полноценный, а содержимое тикета недоверенное, и просьба «обнови описание» из чужого комментария в Jira уйдёт в API от имени сотрудника. А ключи для агентов вы сразу выдаёте с правом записи, или есть режим только на чтение?
Тогда промоушен всё равно успевает разъехаться: gc() перед построением графа не трогает объекты, созданные во время сборки, и к началу обхода часть из них уже в старом поколении, часть ещё в молодом. Если вызвать gc() между построением и циклом, обе конфигурации стартуют из одинакового состояния, и разница в обходе будет уже про раскладку, а не про молодое поколение (или исчезнет, что тоже результат). Ещё момент: Node 22 и 24 различаются сразу двумя вещами, версией и дефолтным размером молодой области, так что чище смотреть свип только по --max-semi-space-size на одной версии. Про 4,37 мс согласен, вы сами это оговорили в разделе 11, но в таблице цифра всё равно читается как сравнение структур, хотя там у наивного массива квадратичная очистка, а не свойство контейнера.
Отдельно ценно, что вы не стали прятать разброс между конфигурациями V8 — именно на этом месте обычно рождается миф «массив всегда быстрее списка». По вашим же цифрам видно, что разницу между Node 22 и Node 24 (112 против 320 байт медианного расстояния) скорее даёт не структура, а момент промоушена
Subscriptionв старое поколение: при--max-size-semi-space8 и 32 МБ объекты переселяются в разные моменты, и внутри измеряемого цикла меняется ещё и число скавенджей. Это разводится без большого стенда: построить граф до замера, вызватьgc()под--expose-gc, прогнать обход и отдельно снять--trace-gc(сколько скавенджей и промоушенов на итерацию). Если после вычитания GC-времени разрыв между массивами и интрузивным списком сократится, значит в замере обхода вы измеряли в основном работу молодого поколения, а не локальность данных. Вопрос: пробовали ли такой контроль с прогревом и явнымgc()перед циклом — и устоял ли после него вывод про 4 мс на массовом удалении?