
--- markdown ---
# Performance Benchmarks

<!-- Generated by scripts/build_release_benchmark_docs.py. Do not edit manually. -->

This page tracks datamodel-code-generator release and main-branch benchmark results collected on GitHub Actions. The data covers only datamodel-code-generator and uses Ubuntu runners so release-to-release changes can be compared without mixing in third-party generator results. Automatic backfills select versions from PyPI download-by-version data when that public dataset is available.

datamodel-code-generator supports many schema styles and production use cases, so it includes a broad set of useful options. As releases add more capabilities, these benchmarks help keep the implementation measured, managed, and tuned so code generation stays fast in everyday use.

## Scenario Guide

Each scenario combines an input type with a case size. This guide is generated from the scenario keys in the benchmark JSON and the collector case definitions, so it changes when the benchmark matrix changes.

| Scenario | Input fixture | Formatters | Represents |
| --- | --- | --- | --- |
| Small / JSON Schema | `tests/data/jsonschema/person.json` | `default` (black/isort default), `builtin` (Built-in), `ruff` (Ruff) | Compact fixture that emphasizes CLI startup, parsing, and formatter overhead for JSON Schema to Pydantic v2 model generation. |
| Large / JSON Schema | `tests/data/performance/large_models.json` | `builtin` (Built-in) | Larger fixture that emphasizes parser and model graph throughput for JSON Schema to Pydantic v2 model generation. |
| Large / OpenAPI | `tests/data/performance/openapi_large.yaml` | `builtin` (Built-in), `ruff` (Ruff) | Larger fixture that emphasizes parser and model graph throughput for OpenAPI component resolution and Pydantic v2 model generation. |

## Interpreting Metrics

- `median_ms` is the primary comparison value: it is the median generation duration after warmup runs, and lower is faster.
- `min_ms`, `max_ms`, and `stdev_ms` describe the measured spread for the same row; wide ranges usually mean CI runner noise rather than a deliberate code change.
- Formatter comparisons are scoped to the same scenario and version. `default` is the black/isort default baseline, while `builtin` and `ruff` ratios compare their medians to that baseline.
- `ok` rows have timing data. `unsupported` means the formatter or option was unavailable in that release. `failed` means installation or command execution failed, so timing cells are intentionally empty.

## Historical Trends

The benchmark data on this page is loaded from `docs/data/release-benchmarks.json` and rendered in the browser. Release runs update that JSON file directly, so the published page reflects new release measurements after the docs deployment without rewriting this Markdown file.

<div class="release-benchmark-app" data-release-benchmark-app data-release-benchmark-state="available">
  <p class="release-benchmark-app__status" data-release-benchmark-status>Loading benchmark data...</p>
  <noscript>JavaScript is required to load the release benchmark data.</noscript>
</div>

## Collection Policy

- The benchmark workflow runs on `ubuntu-24.04`.
- Benchmark results are collected on GitHub Actions CI runners, so median timings can vary slightly with runner load and workflow timing; rerun benchmarks before treating small differences as regressions.
- The Python version is the workflow input, defaulting to the latest configured CI Python.
- Release packages are installed from PyPI in isolated virtual environments.
- The `main` snapshot is installed from the GitHub repository when it is explicitly selected.
- Input coverage currently focuses on OpenAPI and JSON Schema.
- Historical updates commit `docs/data/release-benchmarks.json`; the page renders that JSON client-side.
