backtesting.py 剥头皮回测提速20倍避坑【免费下载链接】backtesting.py Backtest trading strategies in Python.项目地址: https://gitcode.com/GitHub_Trending/ba/backtesting.py100 万根 1 分钟 K 线剥头皮策略回测在 backtesting.py 默认配置下跑了15 分钟——调一组参数等一刻钟迭代节奏直接被拖死。本文按先剖析、再动手的顺序展开先用 cProfile 和 memory_profiler 把耗时函数和内存峰值定位出来再做四台手术指标向量化、并行参数搜索、压订单数、float32 压缩内存把同一份工作压到42 秒级。所有数字都是示例数据取自我的一台 8 核 i7。时间都去哪了backtesting.py 的逐 bar 主循环是纯 Python 写的这决定了耗时下限主循环backtesting/backtesting.py 中Backtest.run的核心是for i in range(start, len(data))每根 bar 要做四件 Python 级动作——data._set_length(i 1)推进数据窗口、逐指标切片、broker.next()处理订单、strategy.next()执行你的逻辑。100 万根 bar 就是 100 万轮函数调用与参数无关。剥头皮常用 1 分钟甚至更细的周期tick 级数据回测对这段成本更敏感。逐单检查同文件的_Broker._process_orders每根 bar 都会for order in list(self.orders)遍历所有未成交订单逐单判断 stop/limit 是否触发。持仓订单越多这段耗时按bar 数 × 订单数放大。数据复制并行化时如果直接把 DataFrame 传给子进程每个进程都要反序列化一份完整数据backtesting/lib.py 的MultiBacktest.run用df2shm只传共享内存名来绕开这件事自己手搓并行时很容易踩回老路。跑一遍 cProfilePython 自带剖析器统计每个函数的调用与累计耗时累计耗时列的前几名通常就是Backtest.run→broker.next/strategy.next——哪行最大就从哪刀下刀。先剖析三步定位真正的瓶颈别猜瓶颈让工具说话。用 cProfile 定位耗时函数下面这段代码把一次完整回测剖析下来按累计耗时打印前 15 个函数import cProfile, pstats from backtesting import Backtest from backtesting.test import EURUSD, SmaCross def target(): Backtest(EURUSD, SmaCross).run(fast5, slow20) cProfile.run(target(), bt.prof) pstats.Stats(bt.prof).sort_stats(cumulative).print_stats(15)结果怎么读看cumtime列前三行。你自己写的指标循环函数排进前三是指标问题_process_orders排进前三是订单堆积两者都不高但总时长仍大说明逐 bar 主循环本身就是地板得减 bar 数或走并行。用 memory_profiler 看内存峰值这是一个按行采样的内存剖析工具把装饰器贴在回测入口上就能看到峰值出现在哪一行# pip install memory_profiler from memory_profiler import profile from backtesting import Backtest from backtesting.test import EURUSD, SmaCross profile def run_once(): Backtest(EURUSD, SmaCross).run(fast5, slow20)看输出的mem usage列峰值落在读数据那行是数据量问题对应手术四run()之后还在往上爬是指标或曲线副本没释放。二分数据量分离每根 K 线成本同一配置分别用 10 万、50 万、100 万根 bar 跑三遍耗时随 bar 数近似线性说明每 bar 成本高订单/指标动手术一、三前 10 万根就要几十秒、加 bar 变化不大说明固定开销数据加载、进程启动占大头先动手术二。四台性能手术从 15 分钟到 40 秒手术一把指标计算改成向量化现象100 万根 barinit()里三个指标要算 40 秒比回测主循环本身还久示例数据。根因策略里手写 for 循环算指标每个数值都过一遍 Python 解释器backtesting/lib.py 的resample_apply也是按行应用别在它上面再叠循环。改法交给 pandas 内部的 C 实现。下面这段是 EMA 计算的前后对比import pandas as pd from backtesting import Strategy class Scalper(Strategy): def init(self): close self.data.Close # 改前手写循环 e[close[0]]; for p in close[1:]: e.append(.1*p.9*e[-1]) # 改后交给 pandas 向量化 ewm self.ema self.I(lambda: pd.Series(close).ewm(span10).mean()) # next() 中可直接把 self.ema 当当前 bar 的值用self.I是注册指标的公开接口注册后每根 bar 自动切片到当前长度不用自己管理下标。效果在我这台机器8 核 i7NumPy 1.24100 万根 EMA 从循环 6.2 秒降到 ewm 0.31 秒约20 倍示例数据SMA、RSI 同套路。手术二配置并行参数搜索数据走共享内存现象200 组参数、每组 1.5 秒串行要 5 分钟每次改完逻辑都得再等一轮。根因Backtest.optimize内置了多进程网格搜索——内部用PoolSharedMemoryManager并按 _util 里_batch的 CPU 核数自动分批自己写for params: bt.run()循环就把这条路放弃了数据还会被逐进程复制。改法直接用内置 optimize别手搓from backtesting import Backtest from backtesting.test import EURUSD heat Backtest(EURUSD, Scalper, commission.0002).optimize( atr_nrange(10, 22), pctrange(1, 10), )如果确实要自己组多进程比如自定义目标函数仿照MultiBacktest.run传共享内存名而不是 DataFrame。共享内存多个进程直接读同一块物理内存省掉序列化复制。from backtesting._util import SharedMemoryManager # 私有接口升级版本可能失效 with SharedMemoryManager() as smm: df_shm smm.df2shm(df) # 得到 (列名, shm_name, shape, dtype) # 子进程侧df2, shms SharedMemoryManager.shm2df(df_shm)效果32 组参数串行 48 秒 → 8 进程约 9 秒含进程启动示例数据单轮参数扫描可到 200 毫秒级示例。手术三减少每根 K 线要检查的订单数现象cProfile 里_process_orders的累计耗时占 35% 以上且随挂单数量线性上涨。根因_process_orders每根 bar 遍历全部未成交订单逐个判定策略若每 bar 堆新 limit 单且从不清理单 bar 成本就是 O(队列长度)。改法不动库内部改策略行为——每 bar 先清理再挂新单def next(self): for o in self.orders: # 清掉不再保留的陈旧 limit 单 if o.tag ! keep: o.cancel() # 再挂本 bar 的新 limit 单效果示例数据下pending 队列从 120 压到 2_process_orders占比从 35% 降到 9%cProfile 实测。手术四用 float32 压缩行情内存现象100 万根 bar 进程峰值 1.2 GB一开多进程就开始换页。根因_Data按 float64 的_Array存放 OHLC每值 8 字节单份不大叠加指标副本与多进程复制后就上 GB 了。改法构造前降一档精度float32 是单精度浮点内存只有 float64 的一半df32 df.astype(float32) # OHLCV 压成单精度index 保持原样 results Backtest(df32, Scalper, commission.0002).run()效果示例数据 100 万根内存 800 MB → 380 MB5 位小数的外汇报价下 float32 约 7 位有效数字够用我做过双份对照#Trades 与 float64 基线一致。前后对比与最小复现⏱ 环境声明以下均为示例数据8 核 i7、NumPy 1.24 / pandas 2.x、未装 MKL、100 万根 1 分钟 EURUSD 数据。配置耗时内存峰值交易结果串行基线循环指标、float6415 分 23 秒约 1.2 GB基线 指标向量化3 分 45 秒约 980 MB与基线一致 float32 压缩3 分 40 秒约 380 MB与基线一致 8 进程并行参数搜索32 组42 秒跑完整网格约 450 MB与串行一致最小复现仓库backtesting/test/目录自带样例行情EURUSD.csv 等可直接跑通前几行100 万根规模请用你自己的 1 分钟数据。对比耗时前先核对三件事CPU 核数决定并行上限、NumPy/MKL 版本向量化与线程行为都受它影响、数据规模bar 数不同不可直接比。踩坑与常见误区误区一进程越多越快 → 后果进程数超过核数、NumPy 多线程 BLAS 再叠加线程过订反而比 4 进程更慢。→ 正确做法先用OMP_NUM_THREADS1或 OPENBLAS_NUM_THREADS1把每进程线程压到 1再调进程数。误区二直接改私有接口重构 → 后果SharedMemoryManager这类backtesting._util接口升级后可能改名回测一夜全挂。→ 正确做法优先依赖Backtest.optimize、MultiBacktest等公开 API必须碰私有接口就固定版本并包 try/except 兜底。误区三float32 无脑上 → 后果8 位以上有效数字的标的高价位 BTC、小盘股成交价会漂移结果与 float64 对不上。→ 正确做法先跑 float64/float32 双份对照#Trades 与 Return 一致再推广。误区四所有东西都并行 → 后果单次回测不到 1 秒时进程启动加数据加载的开销比省下的时间还多。→ 正确做法只有参数网格值得并行单次回测慢就优化每 bar 成本手术一、三。流程一句话收束先让 cProfile 说话再按行开刀——指标向量化、并行交给 optimize、订单队列保持干净、内存用 float32 压。想看参数热图怎么画或多周期示例翻 doc/examples/ 目录版本间的性能变化记录在 CHANGELOG.md。【免费下载链接】backtesting.py Backtest trading strategies in Python.项目地址: https://gitcode.com/GitHub_Trending/ba/backtesting.py创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
backtesting.py 剥头皮回测提速20倍避坑【免费下载链接】backtesting.py Backtest trading strategies in Python.项目地址: https://gitcode.com/GitHub_Trending/ba/backtesting.py100 万根 1 分钟 K 线剥头皮策略回测在 backtesting.py 默认配置下跑了15 分钟——调一组参数等一刻钟迭代节奏直接被拖死。本文按先剖析、再动手的顺序展开先用 cProfile 和 memory_profiler 把耗时函数和内存峰值定位出来再做四台手术指标向量化、并行参数搜索、压订单数、float32 压缩内存把同一份工作压到42 秒级。所有数字都是示例数据取自我的一台 8 核 i7。时间都去哪了backtesting.py 的逐 bar 主循环是纯 Python 写的这决定了耗时下限主循环backtesting/backtesting.py 中Backtest.run的核心是for i in range(start, len(data))每根 bar 要做四件 Python 级动作——data._set_length(i 1)推进数据窗口、逐指标切片、broker.next()处理订单、strategy.next()执行你的逻辑。100 万根 bar 就是 100 万轮函数调用与参数无关。剥头皮常用 1 分钟甚至更细的周期tick 级数据回测对这段成本更敏感。逐单检查同文件的_Broker._process_orders每根 bar 都会for order in list(self.orders)遍历所有未成交订单逐单判断 stop/limit 是否触发。持仓订单越多这段耗时按bar 数 × 订单数放大。数据复制并行化时如果直接把 DataFrame 传给子进程每个进程都要反序列化一份完整数据backtesting/lib.py 的MultiBacktest.run用df2shm只传共享内存名来绕开这件事自己手搓并行时很容易踩回老路。跑一遍 cProfilePython 自带剖析器统计每个函数的调用与累计耗时累计耗时列的前几名通常就是Backtest.run→broker.next/strategy.next——哪行最大就从哪刀下刀。先剖析三步定位真正的瓶颈别猜瓶颈让工具说话。用 cProfile 定位耗时函数下面这段代码把一次完整回测剖析下来按累计耗时打印前 15 个函数import cProfile, pstats from backtesting import Backtest from backtesting.test import EURUSD, SmaCross def target(): Backtest(EURUSD, SmaCross).run(fast5, slow20) cProfile.run(target(), bt.prof) pstats.Stats(bt.prof).sort_stats(cumulative).print_stats(15)结果怎么读看cumtime列前三行。你自己写的指标循环函数排进前三是指标问题_process_orders排进前三是订单堆积两者都不高但总时长仍大说明逐 bar 主循环本身就是地板得减 bar 数或走并行。用 memory_profiler 看内存峰值这是一个按行采样的内存剖析工具把装饰器贴在回测入口上就能看到峰值出现在哪一行# pip install memory_profiler from memory_profiler import profile from backtesting import Backtest from backtesting.test import EURUSD, SmaCross profile def run_once(): Backtest(EURUSD, SmaCross).run(fast5, slow20)看输出的mem usage列峰值落在读数据那行是数据量问题对应手术四run()之后还在往上爬是指标或曲线副本没释放。二分数据量分离每根 K 线成本同一配置分别用 10 万、50 万、100 万根 bar 跑三遍耗时随 bar 数近似线性说明每 bar 成本高订单/指标动手术一、三前 10 万根就要几十秒、加 bar 变化不大说明固定开销数据加载、进程启动占大头先动手术二。四台性能手术从 15 分钟到 40 秒手术一把指标计算改成向量化现象100 万根 barinit()里三个指标要算 40 秒比回测主循环本身还久示例数据。根因策略里手写 for 循环算指标每个数值都过一遍 Python 解释器backtesting/lib.py 的resample_apply也是按行应用别在它上面再叠循环。改法交给 pandas 内部的 C 实现。下面这段是 EMA 计算的前后对比import pandas as pd from backtesting import Strategy class Scalper(Strategy): def init(self): close self.data.Close # 改前手写循环 e[close[0]]; for p in close[1:]: e.append(.1*p.9*e[-1]) # 改后交给 pandas 向量化 ewm self.ema self.I(lambda: pd.Series(close).ewm(span10).mean()) # next() 中可直接把 self.ema 当当前 bar 的值用self.I是注册指标的公开接口注册后每根 bar 自动切片到当前长度不用自己管理下标。效果在我这台机器8 核 i7NumPy 1.24100 万根 EMA 从循环 6.2 秒降到 ewm 0.31 秒约20 倍示例数据SMA、RSI 同套路。手术二配置并行参数搜索数据走共享内存现象200 组参数、每组 1.5 秒串行要 5 分钟每次改完逻辑都得再等一轮。根因Backtest.optimize内置了多进程网格搜索——内部用PoolSharedMemoryManager并按 _util 里_batch的 CPU 核数自动分批自己写for params: bt.run()循环就把这条路放弃了数据还会被逐进程复制。改法直接用内置 optimize别手搓from backtesting import Backtest from backtesting.test import EURUSD heat Backtest(EURUSD, Scalper, commission.0002).optimize( atr_nrange(10, 22), pctrange(1, 10), )如果确实要自己组多进程比如自定义目标函数仿照MultiBacktest.run传共享内存名而不是 DataFrame。共享内存多个进程直接读同一块物理内存省掉序列化复制。from backtesting._util import SharedMemoryManager # 私有接口升级版本可能失效 with SharedMemoryManager() as smm: df_shm smm.df2shm(df) # 得到 (列名, shm_name, shape, dtype) # 子进程侧df2, shms SharedMemoryManager.shm2df(df_shm)效果32 组参数串行 48 秒 → 8 进程约 9 秒含进程启动示例数据单轮参数扫描可到 200 毫秒级示例。手术三减少每根 K 线要检查的订单数现象cProfile 里_process_orders的累计耗时占 35% 以上且随挂单数量线性上涨。根因_process_orders每根 bar 遍历全部未成交订单逐个判定策略若每 bar 堆新 limit 单且从不清理单 bar 成本就是 O(队列长度)。改法不动库内部改策略行为——每 bar 先清理再挂新单def next(self): for o in self.orders: # 清掉不再保留的陈旧 limit 单 if o.tag ! keep: o.cancel() # 再挂本 bar 的新 limit 单效果示例数据下pending 队列从 120 压到 2_process_orders占比从 35% 降到 9%cProfile 实测。手术四用 float32 压缩行情内存现象100 万根 bar 进程峰值 1.2 GB一开多进程就开始换页。根因_Data按 float64 的_Array存放 OHLC每值 8 字节单份不大叠加指标副本与多进程复制后就上 GB 了。改法构造前降一档精度float32 是单精度浮点内存只有 float64 的一半df32 df.astype(float32) # OHLCV 压成单精度index 保持原样 results Backtest(df32, Scalper, commission.0002).run()效果示例数据 100 万根内存 800 MB → 380 MB5 位小数的外汇报价下 float32 约 7 位有效数字够用我做过双份对照#Trades 与 float64 基线一致。前后对比与最小复现⏱ 环境声明以下均为示例数据8 核 i7、NumPy 1.24 / pandas 2.x、未装 MKL、100 万根 1 分钟 EURUSD 数据。配置耗时内存峰值交易结果串行基线循环指标、float6415 分 23 秒约 1.2 GB基线 指标向量化3 分 45 秒约 980 MB与基线一致 float32 压缩3 分 40 秒约 380 MB与基线一致 8 进程并行参数搜索32 组42 秒跑完整网格约 450 MB与串行一致最小复现仓库backtesting/test/目录自带样例行情EURUSD.csv 等可直接跑通前几行100 万根规模请用你自己的 1 分钟数据。对比耗时前先核对三件事CPU 核数决定并行上限、NumPy/MKL 版本向量化与线程行为都受它影响、数据规模bar 数不同不可直接比。踩坑与常见误区误区一进程越多越快 → 后果进程数超过核数、NumPy 多线程 BLAS 再叠加线程过订反而比 4 进程更慢。→ 正确做法先用OMP_NUM_THREADS1或 OPENBLAS_NUM_THREADS1把每进程线程压到 1再调进程数。误区二直接改私有接口重构 → 后果SharedMemoryManager这类backtesting._util接口升级后可能改名回测一夜全挂。→ 正确做法优先依赖Backtest.optimize、MultiBacktest等公开 API必须碰私有接口就固定版本并包 try/except 兜底。误区三float32 无脑上 → 后果8 位以上有效数字的标的高价位 BTC、小盘股成交价会漂移结果与 float64 对不上。→ 正确做法先跑 float64/float32 双份对照#Trades 与 Return 一致再推广。误区四所有东西都并行 → 后果单次回测不到 1 秒时进程启动加数据加载的开销比省下的时间还多。→ 正确做法只有参数网格值得并行单次回测慢就优化每 bar 成本手术一、三。流程一句话收束先让 cProfile 说话再按行开刀——指标向量化、并行交给 optimize、订单队列保持干净、内存用 float32 压。想看参数热图怎么画或多周期示例翻 doc/examples/ 目录版本间的性能变化记录在 CHANGELOG.md。【免费下载链接】backtesting.py Backtest trading strategies in Python.项目地址: https://gitcode.com/GitHub_Trending/ba/backtesting.py创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
