Расширение для GigaCode

GigaPerf

Находит и решает проблемы производительности сервисов. Доказывает измерениями. Переводит в деньги.

Работает в контуре банка: GigaCode · СберЧат · Jira · Bitbucket · SonarQube · DropApp

Смотреть, как работает ↓

Суть

Как это работает

1

Находит

Эвристики, SonarQube, JFR-профиль и DropApp работают независимо друг от друга.

2

Чинит

Точечный фикс подтверждённой находки. Один фикс — один коммит.

3

Доказывает

Тесты и бенчмарк ×5 после каждой правки. Не подтвердилось — git revert.

4

Заводит тикет

Jira: тикет с находкой, обоснованием и findings.json.

5

Открывает PR

Bitbucket: pull request с метриками до и после, ревьюеры назначены.

6

Считает деньги

Ускорение переводится в рубли по тарифу vCPU-часа.

СберЧат

Результаты приходят туда, где живёт команда

Сводка каждого прогона — сообщением в канал команды: что найдено, что исправлено, ссылка на PR и экономия. Запустить прогон можно командой прямо из чата.

GigaPerf09:41

Прогон orders-service завершён

Исправлено: конкатенация в цикле, OrderService.java:24 · 77 → 31 мс (−60%)

Отклонено порогом: 1 фикс (git revert)

PR #482 ждёт ревью · PERF-1247

Экономия: ≈ 29 808 ₽/мес

Открыть PR findings.json

Источники данных

Четыре независимых источника

Статический анализ

Эвристики по таксономии дефектов: от лишних аллокаций до запросов в цикле.

SonarQube

Перф-правила из банковского Sonar по API. Недоступен — прогон продолжается на остальных источниках и помечает деградацию в отчёте.

JFR-профиль

Где в коде горячо: методы, стеки, аллокации, GC — с точностью до строки. Именно это превращает подозрение в адрес фикса.

DropApp

Сколько ресурсов ест сервис в проде: утилизация CPU и памяти, тренды. Подсказывает, где искать, — и подтверждает эффект фикса после выката.

Таксономия

Девять типов дефектов

Избыточные вычисления

одна и та же работа дважды, лишние проходы по данным.

Неэффективные алгоритмы

квадратичная сложность там, где есть линейная.

Неправильное использование функций

полная сущность там, где нужен только факт её существования.

Ошибки в раскладке данных

структура занимает больше памяти, чем нужно.

Избыточные проверки

одно и то же проверяется в трёх слоях, мёртвые ветки.

Ошибки в запросах к базе

лишние round-trip, подзапросы вместо соединений.

Утечка памяти

то, что растёт неограниченно.

Перерасход памяти

не течёт, но занимает кратно больше необходимого.

Избыточная нагрузка на CPU

лишняя работа в горячем пути.

Корреляция

Чинится только подтверждённое

Находки сопоставляются по координатам кода. Чинится только то, что горячо в профиле и подтверждено статикой — или горячо само по себе, тогда фикс формирует LLM.

Холодные срабатывания правил в код не попадают. Они уходят в отчёт — для решения человеком.

То, что не доказано измерением, инструмент не трогает.

Статический анализ SonarQube JFR-профиль DropApp Корреляция findings.json

Демонстрация

Один запуск — от анализа до подтверждённого фикса

$ node .gigacode/skills/performance-optimizer/scripts/run-producers.mjs --root .
чтение MANIFEST.md · set=sandbox · level=soft
[1/4] perf-taxonomy эвристики таксономии · 4 находки · 1,2 с
[2/4] sonar-findings SonarQube · перф-правила · 3 находки · 8,4 с
[3/4] java-perfomance JFR · 60 с записи · 7 горячих методов
[4/4] dropapp утилизация: CPU 87% · RSS +18 МБ/ч · 2 агрегата
корреляция по координатам кода: 16 находок → 9 кандидатов
hot_static 2 горячо в профиле + подтверждено статикой
hot_no_static 0 горячо без статики → LLM-фикс
cold_static 4 холодные срабатывания — только в отчёт
aggregate_no_address 3 агрегаты GC и утилизации без адреса → бенчмарк
план фиксов: 2 · по одному коммиту · после каждого — proof gate
[fix 1/2] OrderService.java:24 · конкатенация строк в цикле
StringBuilder · тесты · бенчмарк ×5: медиана 77 → 31 мс (−60%) · принято
[fix 2/2] ReportDao.java:58 · запрос к базе в цикле
batch-запрос · тесты · бенчмарк ×5: медиана 41 → 39 мс (−4,9%)
ниже порога 5% → git revert · в отчёте как reverted
jira: тикет PERF-1247 создан · вложение findings.json
bitbucket: PR #482 «perf: StringBuilder в OrderService» · ревьюеры назначены
сберчат: сводка отправлена в канал команды
отчёт: .gigacode/reports/sandbox/findings.json · report.md
экономия подтверждённого: −46 мс × 200 RPS × 4,5 ₽/vCPU·ч ≈ 29 808 ₽/мес

Примеры

До и после

Девять классов проблем — от строк до утечек памяти.

ДоPaymentParser.java
18for (Payment p : payments) {
19 Matcher m = Pattern.compile(MASK).matcher(p.getRef());
20 process(m);
21}
ПослеPaymentParser.java
16+private static final Pattern MASK_RE = Pattern.compile(MASK);
18for (Payment p : payments) {
19+ Matcher m = MASK_RE.matcher(p.getRef());
20 process(m);
21}

PaymentParser.java:19 · медиана 96 мс → 22 мс (−77%)

Отчёт

findings.json

{
"file": "src/main/java/…/OrderService.java",путь от корня проекта
"line_from": 22, "line_to": 26,
"family": "memory",db · cpu · memory · algo · redundant
"pdf_taxonomy": ["T2", "T8"],коды таксономии
"mechanism": "конкатенация строк в цикле",почему это дорого — одним предложением
"impact": "лишние аллокации нагружают GC",
"fix": "собирать строку через StringBuilder",
"evidence": {
"channel": "X-Elapsed-Ms",канал измерения
"before": 77, "after": 31,медианы до и после, мс
"how": "бенчмарк ×5, тот же харнесс"как воспроизвести
}
}

Проверено — и не дефект

Отдельный раздел checked_but_not_an_issue. Что инструмент проверил, почему это не проблема — чтобы команда не проверяла второй раз.

Экономика

Миллисекунды в рубли

46 мс
200
4,5 ₽

29 808 ₽/мес

9,2 vCPU · 994 ₽ в день

Δмс × RPS × тариф vCPU-часа

Зелёный коридор

Если после фиксов сервису больше не нужны текущие лимиты по ресурсам, их срезают до фактического потребления с запасом. Освобождённые vCPU из калькулятора — целевой уровень, а замеры DropApp и findings.json — готовое обоснование заявки.

Безопасность правок

Каждая правка проверяется

Один фикс — один коммит. После каждого — тесты и повторный бенчмарк: не меньше 5 прогонов, порог ≥5% медианы.

Не подтвердилось — автоматический git revert. Код меняет только отдельный модуль.

Полный журнал действий. Что читал, что предлагал, что менял.

Внедрение

Сделан для закрытого контура

Полностью офлайн

Ни одного внешнего вызова. Данные и код не покидают контур банка.

Ничего не закупать

Использует то, что уже есть: GigaCode, SonarQube, DropApp, JDK, Jira, Bitbucket.

Деградирует без падений

Недоступен Sonar или JDK — прогон продолжается на оставшихся источниках и помечает режим в отчёте.

Установка

Три шага

  1. 1Скопируйте директорию .gigacode в корень проекта.
  2. 2Задайте параметры в MANIFEST.md.
  3. 3Запустите.

Нужен только Node.js. Всё остальное — инструменты, которые уже есть в контуре.

Промпт для GigaCode

Используй performance-optimizer.
Проанализируй репозиторий, собери свидетельства всеми продюсерами,
скоррелируй и сформируй findings.json. Код не изменяй.

FAQ

Вопросы

Что нужно для установки?

Node.js и GigaCode. Артефакт ставится копированием одной директории .gigacode в корень проекта.

Данные покидают контур?

Нет. Ни одного внешнего вызова: анализ, фиксы и отчёты — целиком внутри инфраструктуры банка.

Что, если фикс сломает тесты?

Автоматический git revert. Правка попадает в отчёт со статусом reverted и причиной.

Что, если SonarQube недоступен?

Прогон продолжится на эвристиках, JFR-профиле и данных DropApp, а деградация будет явно помечена в отчёте.

Как проверить ваши цифры?

В каждой находке — канал измерения, значения до и после и команда воспроизведения. Полный журнал действий — в runlog.

Чем это отличается от простого запуска SonarQube?

Sonar выдаёт все срабатывания правил без приоритета. GigaPerf оставляет только то, что горячо в профиле, чинит подтверждённое и измеряет эффект каждого фикса. Холодные срабатывания уходят в отчёт без правок.

Что будет, если находок нет?

Пустой findings.json — тоже результат. Раздел checked_but_not_an_issue покажет, что именно проверено и почему это не дефекты. Инструмент не выдумывает находки ради отчёта.

Безопасно ли запускать на рабочем репозитории?

Анализ полностью read-only. Правки вносит отдельный модуль и только по явному запросу: один фикс — один коммит, провал проверок — автоматический git revert.

Сколько занимает прогон?

Минуты. Эвристики отрабатывают за секунды, Sonar отвечает по API, JFR пишет столько, сколько идёт нагрузка — в демо это 60 секунд.

Почему только Java?

Продюсер динамики построен на JFR, поэтому старт — Java. Контракт находок и оркестрация языконезависимы: продюсер для другого стека подключается тем же форматом.

Производительность можно измерить.
И перевести в рубли.

Смотреть, как работает ↑