GoCPG vs Joern: Сравнительный анализ¶

Дата: 2026-02-25 Joern: 4.0.426 (flatgraph) GoCPG: 0.1.0 (DuckDB) Кодовые базы: GoCPG (Go, 215 файлов), CodeGraph (Python, 1183 файла)

Резюме¶

GoCPG в 3.9x быстрее Joern при генерации CPG и создаёт более богатые графы с дополнительными типами рёбер (DDG, PDG, eval_type, binds_to). Joern генерирует в 2.6x больше CDG-рёбер из-за моделирования вызовов функций как точек ветвления (пути исключений). Оба инструмента используют идентичные базовые алгоритмы (доминаторы Cooper-Harvey-Kennedy, CDG по Ferrante-Ottenstein-Warren). Ключевое архитектурное различие: GoCPG — нативный Go-бинарник с записью напрямую в DuckDB, Joern — JVM/Scala-система с in-memory flatgraph.

1. Производительность¶

Парсинг + полный конвейер анализа¶

Время по пассам (Go)¶

Преимущество GoCPG: конвейер на основе DAG выполняет все 30 пассов параллельно с разрешением зависимостей. Joern выполняет пассы последовательно.

Память и хранение¶

2. Сравнение узлов¶

Go кодовая база (исходники GoCPG, 215 файлов)¶

Уникальные узлы GoCPG (отсутствуют в Joern): - finding (1,199) — результаты анализа шаблонов - binding (6,253) — привязки тип-метод - field_identifier (19,876) — доступ к полям структур - modifier (670) — модификаторы видимости - import (1,097) — объявления импортов - method_parameter_out (8,900) — выходные параметры - type_ref (2,137) — ссылки на типы

Python кодовая база (CodeGraph, 1183 файла)¶

3. Сравнение рёбер¶

Go кодовая база¶

Python кодовая база¶

Примечание: 15.9M call-рёбер Joern для Python — результат NaiveCallLinker, который агрессивно связывает все вызовы по имени (~10x ложных срабатываний).

4. Анализ расхождения CDG: 59K vs 153K¶

Ключевая находка¶

При почти идентичном числе CFG-рёбер (270K vs 268K), Joern создаёт в 14.2x больше ветвящихся узлов:

Причина¶

Joern моделирует каждый вызов функции как точку ветвления — вызов может вернуть результат нормально или выбросить исключение (два пути). В Go, где ошибки обрабатываются явными возвратами (if err != nil), а не исключениями, это создаёт 13,031 ложное ветвление.

Цепочка влияния¶

Больше ветвящихся узлов → Другие деревья постдоминаторов →
Большие постдоминаторные фронтиры → Больше CDG-рёбер

GoCPG:    970 ветвящихся →  59K CDG
Joern: 13,734 ветвящихся → 153K CDG

Корректность для Go¶

Для Go CDG GoCPG точнее: Go не использует try/catch исключения. Моделирование путей исключений Joern создаёт ложные зависимости управления, которых нет в реальном потоке.

Алгоритмы идентичны¶

5. Архитектурное сравнение¶

Проектирование конвейера¶

Конвейер анализа¶

Уникальные возможности GoCPG¶

1. DDG/PDG — рёбра зависимостей данных и программных зависимостей
2. AliasAnalysisPass — внутрипроцедурный анализ указателей (p = &x → pts[p]={x}, копирование указателей, разрешение p->field → obj.field)
3. Межпроцедурный Reaching Def — анализ потока данных между функциями + распространение побочных эффектов глобальных переменных
4. Тернарные косвенные вызовы — (cond ? f1 : f2)(args) создаёт отдельные CallNode для каждой ветви (C/C++)
5. PatternMatchPass — структурный поиск шаблонов в конвейере
6. FindingGenerationPass — находки качества/безопасности как узлы CPG
7. DomainAnnotationPass — доменная разметка (PostgreSQL, Django и др.)
8. VCSTagPass — теги автора, частоты изменений из git
9. Watch mode — наблюдение за файловой системой с live-обновлением CPG
10. Инкрементальные обновления — на основе git diff с отслеживанием веток и поддержкой слияний
11. DuckDB — SQL-запросы без JVM

Уникальные возможности Joern¶

1. Интерактивный REPL — Scala-консоль для ad-hoc запросов
2. 13 модулей анализа (vs 11 у GoCPG) — Ruby, Swift
3. GHIDRA — анализ бинарников
4. NaiveCallLinker — агрессивное связывание вызовов по имени
5. PythonTypeRecovery — итеративный вывод типов (2 прохода)

6. Сравнение потоков данных¶

Reaching Definitions¶

Граф вызовов¶

7. Паритет по Python (с коррекцией дупликации)¶

Ошибка: дупликация путей к файлам (~2x раздувание)¶

GoCPG имеет ошибку нормализации путей: каждый исходный файл сохраняется с абсолютным (D:\work\codegraph\src\...) и относительным (..\src\...) путём, создавая ~2x FILE-узлов и дублируя все содержащиеся узлы/рёбра.

Причина: orchestrator.go:280 использует абсолютные пути из filepath.WalkDir(). Резолвинг импортов/типов в Python-модуль анализае создаёт записи с относительными путями. CPGGraph.filesByName использует путь как ключ — оба варианта сосуществуют. full_name метода включает путь к файлу (filepath:ClassName.method), поэтому дедупликация по full_name не работает.

Сравнение узлов (дедупликация)¶

Используя только абсолютные пути как истинные дедуплицированные значения:

Сравнение рёбер (оценка /2)¶

Примечание: 15.9M call-рёбер Joern — результат NaiveCallLinker (~18x ложных срабатываний). FQN-резолвинг GoCPG значительно точнее.

Вердикт по Python¶

Паритет достигнут на ключевых метриках после коррекции дупликации: - Внутренние методы: -10% — незначительное расхождение в генерации синтетических методов - CFG: +10%, Reaching defs: -3%, AST: +9% — всё близко к паритету - CDG: +34% — ожидаемо: GoCPG правильно моделирует ветвление исключений Python - Граф вызовов: GoCPG в 18x точнее NaiveCallLinker Joern - Эксклюзивно: DDG, PDG, eval_type, binds_to — только GoCPG

8. Покрытие языков¶

9. Итоговая таблица¶

Создано: 2026-02-25 | GoCPG v0.1.0 vs Joern v4.0.426