GigaPerf — производительность с доказательствами

Суть

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

1

Находит

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

2

Чинит

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

3

Доказывает

Тесты и бенчмарк 10 + 10 после каждой правки. Улучшение статистически не значимо — git revert.

4

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

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

5

Открывает PR

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

6

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

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

Перечень дефектов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СберЧат

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

Сводка каждого прогона — сообщением в канал команды: что найдено, что исправлено, ссылка на 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-профиль + DropApp

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

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

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

$ gigacode

/performance-optimizer

чтение MANIFEST.md · set=sandbox · level=soft

[1/3] perf-taxonomy эвристики перечня · 4 находки · 1,2 с

[2/3] sonar-findings SonarQube · правила производительности · 3 находки · 8,4 с

[3/3] java-perfomance JFR · 60 с записи · 7 горячих методов

+ 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 · тесты ✓ · бенчмарк 10+10: медиана 77 → 31 мс (−60%) · p < 0,001 · принято

[fix 2/2] ReportDao.java:58 · запрос к базе в цикле

batch-запрос · тесты ✓ · бенчмарк 10+10: медиана 41 → 39 мс (−4,9%) · p = 0,19

улучшение не значимо (α = 0,05) → 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 · медиана 24 мс → 19 мс (−21%)

Отчёт

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": "бенчмарк 10+10, тот же харнесс"как воспроизвести

}

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

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

Экономика

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

10 + 10

прогонов бенчмарка

до фикса и после, один харнесс. Минимум для мощности рангового критерия при α = 0,05; медиана гасит шум JIT и GC.

α = 0,05

односторонний критерий Манна — Уитни

задержки не нормальны, поэтому сравниваются ранги выборок, а не средние.

proof gate

✗ не значимоp ≥ 0,05 git revert дефект в отчёте — reverted

✓ значимоp < 0,05 Δ = медиана до − медиана после

₽/мес

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

эту формулу крутит калькулятор ниже.

Δмс на операции46 мс

RPS200

Тариф, ₽/vCPU-час4,5 ₽

29 808 ₽/мес

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

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

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

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

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

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

Один фикс — один коммит. После каждого — тесты и повторный бенчмарк: 10 прогонов до и 10 после, значимость улучшения — по критерию Манна — Уитни.

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

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

Внедрение

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

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

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

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

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

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

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

Установка

Три шага

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

Скачать расширениеGigaPerf-extension.zip · 14 КБ

Нужен только 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. Контракт находок и оркестрация языконезависимы: продюсер для другого стека подключается тем же форматом.

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

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