Используйте этот сценарий, когда есть измеренная проблема задержки, пропускной способности, CPU, памяти, ввода-вывода или конкуренции и нужно сузить ответственный участок кода. CodeGraph ранжирует структурных кандидатов и показывает вызывающий код. Статический анализ формирует гипотезу; измерения на выбранной нагрузке показывают её влияние на производительность.
Как CodeGraph сужает поиск
Сценарий сначала пробует обработчики типовых запросов. Для остальных запросов он объединяет несколько видов анализа: поиск потенциальных узких мест по шаблонам кода, анализ графа вызовов и анализ использования ресурсов. Граф помогает выделить связанные функции, циклы и пути вызовов. На основе находок сценарий готовит рекомендации и расставляет приоритеты исследования.
Используйте результат вместе с профилем вашей нагрузки. Например, если выросло время ответа при увеличении параллелизма, начните с функций в медленной трассе. Сопоставьте их с кандидатами CodeGraph, изучите зависимости и выберите один участок для эксперимента. Изменение проверяйте на той же нагрузке: так вы свяжете структурную находку с измеренным результатом.
Сначала определите измерение
Зафиксируйте нагрузку, входные данные, прогрев, параллелизм, число выборок, процентиль или метрику пропускной способности, оборудование, среду исполнения и конфигурацию. До и после изменения условия должны совпадать.
{
"measurement_environment": "<оборудование, runtime, конфигурация, данные>",
"baseline_measurement": "<метрика, значение, число выборок>",
"candidate_measurement": "<та же метрика после изменения>"
}
Сохраните устойчивое исходное измерение. После изменения сложности кода или цепочки вызовов повторите замер и сравните результаты.
Типизированный запрос на исследование
Подготовьте окружение по руководству CLI и проект, граф и LLM-провайдер по руководству программного вызова. Выполняйте Python из корня репозитория CodeGraph. Пример — шаблон для существующей согласованной задачи: замените project_key, namespace, <task-id>, ссылки на измерения и путь исходника её точными значениями. Ссылки должны вести на доступные результаты профилирования и измерений; заполнители не создают такие результаты.
Перед исследованием подготовьте зарегистрированный проект и CPG, соответствующий ревизии профиля или трассы. Используйте ролевой сценарий разработчика с принятой задачей:
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Ранжируй пути кода, которые могут объяснить измеренную регрессию задержки запроса.",
employee_id="codegraph_developer",
scenario_id="scenario_06",
event_type="implementation_start",
context={
"project_key": "codegraph",
"namespace": "default",
"task_id": "<task-id>",
"source_refs": ["<profile-or-trace-ref>", "<benchmark-ref>"],
"file_paths": ["<bounded-source-path>"],
},
)
result = invoke_role_bound_scenario_request(request)
if result.get("error"):
raise RuntimeError(result["error"])
print(result["scenario_id"])
print(result.get("answer") or "")
При отсутствии project_key, namespace или task_id контракт закрывается с ошибкой role_bound_scenario_contract_missing. Для codegraph_developer сценарий условный, поэтому запрос должен называть реальный симптом производительности.
Ожидайте scenario_06 и ответ, который связывает кандидатов с заданным симптомом. Проверьте metadata.role_bound_scenario_invocation, текущую ревизию и ссылки на код. Ошибка, пустой ответ или неактуальный граф не подтверждают успешное исследование. Для отрицательной проверки передайте context={}: до исследования должен возникнуть RuntimeError с role_bound_scenario_contract_missing. Восстановите точную область перед повтором.
Проверьте область влияния
В PowerShell замените <symbol> на существующее имя метода и <cpg-path> на базу выбранного проекта. Для команды нужен доступный GoCPG gRPC:
python -m src.cli impact "<symbol>" --db "<cpg-path>" --format json
Используйте вызывающий код, затронутые методы, глубину и оценку влияния для выбора участка проверки. При пустом списке проверьте имя символа и актуальность CPG, затем сопоставьте связи с исходниками. Подтвердите изменение тестами и измерением производительности на выбранной ревизии.
Цикл оптимизации от теста
- Воспроизведите проблему с зафиксированной нагрузкой и сохраните
baseline_measurement. - Свяжите симптом с одним ограниченным путём кода по профилю, трассе или счётчикам.
- Проверьте в CodeGraph вызывающий код, зависимости и риски этого пути.
- Добавьте регрессионный тест корректности и, если измерение достаточно устойчиво, пороговый или сравнительный тест производительности.
- Внесите одно небольшое изменение без несвязанной чистки.
- Запустите тесты корректности, тот же замер производительности и ту же конфигурацию профилировщика.
- Сохраните
candidate_measurement, разброс и регрессии; оставьте изменение только при воспроизводимом улучшении.
Сравнивайте распределения или несколько прогонов, а не один самый быстрый результат. Если отличие укладывается в обычный шум, укажите неопределённость.
Условия остановки
Остановитесь, если измерение не воспроизводится, изменились среда или данные, кандидат пересекает несогласованную границу API, авторизации или хранения либо выигрыш требует ослабить корректность или безопасность. Верните гипотезу и недостающие свидетельства вместо заявления об успехе.
Связанные материалы
Для подготовки изменений используйте разработку функции, а для привязанного к ревизии ревью — проверку кода.