# 基准测试 (/zh/features/performance/benchmarks)

了解 VBT 在数百万根 K 线和订单上的回测速率。通过下方交互式比较，探索从高层 Python 调用到底层 Rust
模拟的性能。每项结果使用相同数据和订单，通过正确性检查，并附有可在自己机器运行的代码。

## 比较回测速率 \[#compare-backtesting-speed]

在下方选择任务类型和每列行数。稀疏订单展示扫描长历史、偶尔交易的成本；密集订单展示每根 K 线都产生订单时的成本。若使用 VBT 的 Python 投资组合 API，应从高层结果看起。

跨回测库与输入规模的交互模拟基准测试（面板为英文）。[基准测试套件（ZIP）](/downloads/simulator-showdown.zip)

每个模拟器接收相同的一分钟 K 线和订单：稀疏任务每列只有少量订单，密集任务每根 K 线都有订单。只有成交订单、最终持仓和投资组合净值一致，结果才计入。VBT 分三个 API
层级运行：高层投资组合构建、使用预处理输入的中层模拟，以及底层订单处理，每层均测试 Numba 和 Rust。

8 列并行、每列 1,000,000 根 K 线时，稀疏任务在底层 Rust 模拟器耗时 1.7 毫秒，经高层 Rust 耗时 25 毫秒，Manifold-BT 为 42 毫秒，Backtrader
为 65 秒。包含 8,000,000 个订单的密集任务，高层 Rust 耗时 178 毫秒，Manifold-BT 为 213 毫秒，Backtrader 未能在 300
秒限制内完成。半透明标记表示首次调用：Numba 首次使用需编译，高层约耗时 16 秒，而 Rust 已提前编译。全部数值在 8 核 Apple M3 上测得，各库版本显示在图表提示中。ZIP
文件包含可复现测试的完整框架。

## 哪种基准符合您的研究？ \[#which-benchmark-matches-your-research]

| 您的工作流                | 比较什么                 |
| -------------------- | -------------------- |
| 从 Python 构建投资组合并检查结果 | 包含输入准备和投资组合构建的高层调用。  |
| 在反复模拟中复用预处理数组        | 输入已准备完毕、只计时模拟器的中层调用。 |
| 编写自定义数值模拟循环          | 由您处理外围流程的底层订单处理。     |
| 大部分时间用于指标或绩效度量       | 下方函数基准，输入形状应接近自己的数据。 |

预热后的耗时有助于估计重复研究的成本。首次调用耗时在启动新脚本或工作进程时更重要。两者同时展示，便于判断自己的工作流适用哪种成本。[Rust 引擎](/zh/features/performance/native-rust/)页还展示根据成交反馈进行回调的策略，[并行执行与缓存](/zh/features/performance/parallel-execution-and-caching/)则展示附带内存实测的大规模参数扫描。

## 为函数做基准测试 \[#benchmarking-your-functions]

软件包包含针对自身函数的基准引擎。`vbt.run_benchmarks`
生成指定形状、固定随机种子的输入，检查后端输出是否一致，再分别计时。检查包括返回值和已注册的原地输出，因此耗时对应的是经过验证的计算：

```python title="Compare Numba and Rust on six functions with 100,000 × 10 inputs"
>>> results = vbt.run_benchmarks(
...     input_model="2d",
...     backend_ids=("nb", "rs"),
...     patterns=[
...         "generic.rolling.rolling_mean",
...         "generic.rolling.ewm_mean",
...         "generic.base.crossed_above",
...         "returns.sharpe_ratio",
...         "returns.max_drawdown",
...         "portfolio.from_signals.from_signals",
...     ],
...     rows=100_000,
...     cols=10,
... )
>>> rows = {}
>>> for r in results:
...     ms = {backend: s * 1e3 for backend, s in r.runtime_by_backend.items()}
...     rows[r.name] = ms | {"speedup": r.speedup}
>>> pd.DataFrame(rows).T.round(2)  # (1)
                                                  nb      rs  speedup
generic.base.crossed_above                      4.45    5.67     0.78
generic.rolling.ewm_mean                        5.46    2.35     2.32
generic.rolling.rolling_mean                    3.81    3.96     0.96
portfolio.from_signals.from_signals[dense]    167.33  180.72     0.93
portfolio.from_signals.from_signals[grouped]  134.67  129.49     1.04
portfolio.from_signals.from_signals[sparse]    14.15   11.91     1.19
returns.max_drawdown                            2.73    0.94     2.92
returns.sharpe_ratio                            4.55    1.09     4.19
```

1.  Apple M3 上每次调用的毫秒数，先预热两次，再取五次运行中的最短耗时。加速比为 Numba 耗时除以 Rust 耗时。

Rust 在夏普比率上快四倍以上，在最大回撤上快近三倍，而在滚动均值、交叉判断和密集模拟上略慢。这些结果说明 VBT
为什么不预设某个后端始终更快。命令行版本可对整类函数运行相同引擎，完整矩阵覆盖软件包中几乎所有函数，详见下方[基准测试](#benchmarks)功能介绍。

生成的矩阵报告除结果外，还记录 CPU、操作系统、Python 和软件包版本、Rust
工具及选定的线程设置。可以随研究保存报告，并用相同任务比较新环境。先从最常用的函数开始，需要更全面覆盖时再扩展到完整矩阵。

## 按实测选择后端 \[#measured-backend-selection]

AutoBench 使用这些测量结果。在本机建立基准缓存后，设置
`vbt.settings.jitting["backends"]["auto_mode"] = "bench"`，即可根据保存的耗时和输入形状选择符合条件的后端；`"bench_mixed"`
还会在串行与并行版本之间选择。策略规则使选择保持保守：默认要求候选后端至少比默认后端快
5%，并可使用多次实测中的最小值或其他统计量比较。[计算后端](/zh/features/performance/compute-backends/)页介绍其他后端选择方式。

## 测量自己的代码 \[#measuring-your-code]

`vbt.Timer` 和 `vbt.MemTracer` 可测量代码块的耗时和被跟踪内存的峰值，见下方[资源管理](#resource-management)功能介绍。`vbt.timeit`
为函数计时并返回易读时长，`@vbt.with_timer` 和 `@vbt.with_memtracer` 装饰器则打印每次函数调用的时间或内存。

测量实际运行的各阶段：准备数据、计算信号、模拟订单，以及构建要保留的统计量。这能显示更快的后端、输入复用或更小的[分块](/zh/features/performance/parallel-execution-and-caching/#splitting-work-into-chunks)在哪些环节有帮助。`MemTracer`
使用 Python 的 `tracemalloc` 跟踪代码块中的内存分配。规划 RAM 能容纳多少工作进程时，也应测量整个进程的内存。

小输入主要测到固定开销。在构建本页的机器上，一次 `vbt.PF.from_signals` 调用处理 365 根 K 线耗时 5.3 毫秒，处理 100,000 根耗时 6.4
毫秒：几乎全部时间用于准备输入和构建投资组合，而非模拟。因此，仅比较一年日线数据，难以说明大规模性能。大量小回测作为一次调用的多列运行，或使用上方对比中的底层函数，速度通常更快。

!!! tip "测试实际使用的任务"
    速度取决于函数、输入形状与内存布局、核心数量，以及代码是否已编译。在自己的数据和硬件上，先预热一次，再测量任务中耗时最多的调用。

## 基准测试 \[#benchmarks]

新增于 v2026.6.27

✅ VBT 现已为几乎整个代码库提供兼顾正确性的后端基准测试。最新概览涵盖 **748** 个函数、**768** 个变体、**1,976** 个内核、**15,709** 个用例，以及
**59,600** 次基准运行，覆盖 Numba、Rust、直接后端调用、AutoBench 和
AutoBenchMixed。性能由此可被检查：用户能看到哪个后端在哪种输入大小下领先，以及并行执行是否值得用于自己的任务。

=== "定向运行"
    ```bash title="Benchmark one family from the terminal"
    python -m vectorbtpro.benchmarks.bench_engine_cli \
      --backend nb \
      --backend rs \
      --input-model 1d \
      --pattern returns
    ```

    ```python title="Run the same benchmark from Python"
    >>> results = vbt.run_benchmarks(
    ...     input_model="1d",
    ...     backend_ids=("nb", "rs"),
    ...     patterns=["returns"],
    ... )
    >>> print(results)  # (1)
    function,task_id,ndim,shape,nb_s,rs_s,speedup,auto_bench_backend,nb_elapsed_s,rs_elapsed_s
    ...
    ```

    1.  结果以 CSV 输出，包括各后端运行时间、加速比、基准测试总耗时，以及适用时 AutoBench 选中的后端。默认先检查输出一致性，再计时。

=== "完整矩阵"
    ```bash title="Generate cache, reports, and SVG plots"
    python -m vectorbtpro.benchmarks.bench_matrix_cli --full --write-plots
    ```

    !!! info "说明"
        完整矩阵会跨多个后端、形状和执行模式测试数千个用例，可能耗时较长。完整运行写出 Markdown 报告、`cache.json`、`runtime.svg` 和
        `speedup.svg`。写出图表还需要 Kaleido 等 Plotly 静态图像导出引擎。

按后端和元素总数排列的基准测试中位运行时间排名. [Figure data (JSON)](/assets/figures/features/productivity/benchmark-runtime.7d417eb67553.json)

## 资源管理 \[#resource-management]

新增于 1.0.0

✅ 新增性能分析工具，帮助测量任意代码块的执行时间和内存占用 🧰

```python title="Profile getting the Sharpe ratio of a random portfolio"
>>> data = vbt.YFData.pull("BTC-USD")

>>> with (
...     vbt.Timer() as timer,
...     vbt.MemTracer() as mem_tracer
... ):
...     print(vbt.PF.from_random_signals(data.close, n=100, seed=42).sharpe_ratio)
1.0410760501518814

>>> print(timer.elapsed())
74.15 milliseconds

>>> print(mem_tracer.peak_usage())
459.7 kB
```