NautilusTrader Derive 适配器基准测试深度解析入站解码、签名与分发管道的性能剖析【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader本文基于 crates/adapters/derive/benches/BENCHMARKS.md 展开系统讲解 NautilusTrader 中 Derive 交易适配器的四组 Criterion 基准测试套件data、exec、micros、signing其测量环境与复现方法、每条基准的语义定义、实测数据表以及源码层面的性能结论如RawValue单趟解码、EIP-712 签名主导执行路径等。读完本文你将掌握 Derive 适配器端到端热路径的成本分布能够在自己的机器上复现这套基准并用micros.rs组件分解快速定位管道性能回归的来源。基准测试定位文档即基线DeriveDerive.xyz是一个基于链上结算的衍生品交易所其 NautilusTrader 适配器位于 crates/adapters/derive核心 crate 名为nautilus-derive。适配器需要同时处理两套截然不同的工作负载一是高频的 WebSocket 行情入站流盘口增量、ticker、成交、资金费率、期权 Greeks 等二是每次下单都必须执行的链上签名路径EIP-712 订单签名 REST 请求鉴权。依据仓库根目录 BENCHMARKING.md 中基准即文档Benchmarks are documentation的原则本文件记录的是热路径的构成、实测输入与成本快照供后续优化和回归对照使用。文中所有数字均于 2026-05-30 在 AMD Ryzen Threadripper 9980X 上测得rustc 1.95.0bench-ltoprofilerelease 优化 lto fatcodegen-units 1且保留debug full调试符号。CPU governor 固定为performance并通过setarch -R关闭 ASLR套件先完整跑一遍以预热缓存、稳定时钟再进行正式测量——冷启动首次运行会令每行数字虚高约 10%。需要强调的是绝对数值因机器而异只有同机对比same-machine deltas才有意义。该文件的刷新时机为实质性性能变更时或发布前同时更新测量日期。如何复现环境控制与命令序列由于基准对 CPU 频率、ASLR、缓存与散热状态敏感复现必须遵循严格的环境控制流程# 1. 锁定 CPU 为 performance 调度器需要 root sudo cpupower frequency-set -g performance # 2. 关闭 ASLR 并执行预热运行结果不计入 setarch -R cargo bench -p nautilus-derive --profile bench-lto \ --bench data --bench exec --bench micros --bench signing # warm-up # 3. 正式测量 setarch -R cargo bench -p nautilus-derive --profile bench-lto \ --bench data --bench exec --bench micros --bench signing # measured # 4. 恢复默认 governor sudo cpupower frequency-set -g powersave # restore default--profile bench-lto与cargo bench默认的benchprofile 的关键区别在于bench-lto增加lto fat与codegen-units 1与生产 release 二进制保持一致因此发布到 BENCHMARKS.md 的基线数字必须使用 bench-lto详见 BENCHMARKING.md 的 Measurement requirements 一节。更完整的降噪策略见仓库根目录 BENCHMARKING.md。四个 bench 目标在 crates/adapters/derive/Cargo.toml 中注册harness false即使用 Criterion 自带 harness共享 benches/common/mod.rs 中的 fixture 与工具函数。入站 fixture 直接include_str!引入 test_data 下真实抓取的交易所数据在 bench 设置阶段由subscription_frame包装成线上投递的 JSON-RPC subscription 信封因此基准输入与解析器测试语料保持同步。入站管道data.rs原始 WS 字节到 Nautilus 域类型data.rs测量的是从原始 WebSocket 帧字节到 Nautilus 域类型的完整入站链路覆盖帧解码单趟解析为类型化帧 频道解码原始 payload 字节到类型化结构体 解析 Nautilus 类型构造。基准循环内无 I/O、无异步运行时、无 channel仅测纯 CPU 计算。各行的输入来自test_data的真实捕获benches/common/mod.rs 中fixtures模块定义了频道与数据book_deltasorderbook.ETH-PERP.1.10频道盘口快照增量ws_orderbook_eth.jsonquotes/mark_price/index_price/funding_rateticker_slim.ETH-PERP.1000频道perp slim tickerws_ticker_slim_eth.jsontradestrades.perp.ETH频道公开成交ws_trade_eth.jsonbarsREST OHLCV 路径http_public_candles_eth.json因为Derive 没有 WS K 线频道该行解码 candle 记录并构造Baroption_greeksticker_slim.ETH-20260627-3500-C.1000期权频道ws_ticker_slim_eth_call.json行序从最基础的行情流盘口增量向下经过 ticker 衍生流quotes/mark/index/funding/bars最后是期权专属的 Greeks 流BenchMedianThroughputinbound_pipeline/book_deltas473 ns2.12 M/sinbound_pipeline/quotes1.64 µs610 k/sinbound_pipeline/trades742 ns1.35 M/sinbound_pipeline/mark_price1.59 µs631 k/sinbound_pipeline/index_price1.59 µs631 k/sinbound_pipeline/funding_rate1.57 µs639 k/sinbound_pipeline/bars670 ns1.49 M/sinbound_pipeline/option_greeks2.35 µs426 k/s从源码看benches/data.rs每条基准都走同一条调用链DeriveWsFrame::parse帧层→ 频道解析如parse_orderbook_msg/parse_ticker_msg/parse_trades_msg→ 域解析parse_orderbook_deltas、parse_ticker_quote、parse_trade_tick、parse_candle_record、parse_option_greeks等均位于 src/websocket/parse.rs。价格与数量精度由 ETH-PERP 合约属性决定PRICE_PRECISION 2tick_size 0.01、SIZE_PRECISION 3amount_step 0.001。执行管道exec.rs策略命令到待发送的线上字节exec_pipeline测量从策略命令OrderAny/ cancel到可发送的线上字节的整条出站路径submit_limit/submit_market/modify覆盖签名路径private/order与private/replace完整流程为 normalize订单归一化→ ABI encode → EIP-712 签名 → JSON 序列化。submit_market额外携带限价保护参数Some(dec!(3500))cancel覆盖无签名路径private/cancel构建参数 序列化Derive 只支持 Limit 与 Market 两种订单类型因此没有止损单stop-order基准行。BenchMedianThroughputexec_pipeline/submit_limit42.1 µs23.8 k/sexec_pipeline/submit_market42.1 µs23.7 k/sexec_pipeline/modify42.1 µs23.7 k/sexec_pipeline/cancel45.8 ns21.8 M/s出站负载构造由 src/http/query.rs 的order_to_derive_payload/order_replace_to_derive_payload完成。基准中使用的签名上下文SESSION_KEY、钱包地址、SUBACCOUNT_ID 30769、EXPIRY_SEC取远未来时间戳以通过 EIP-712 过期守卫定义了签名基准的固定输入。签名基准signing.rsEIP-712 与 EIP-191 的成本解剖signing.rs把执行路径中最昂贵的部件单独抽出来测sign_trade_actionEIP-712 订单签名ABI encode keccak secp256k1每笔订单提交支付一次。基准构造SignedAction::new后调用action.sign(signer)rest_auth_headersEIP-191 时间戳签名build_rest_auth_headers_at每个 HTTP 读请求支付一次signer_from_keysecp256k1 私钥展开PrivateKeySigner::from_str客户端启动时支付一次abi_encode_tradeTradeModuleData的 ABI 编码签名前的一小步nonce_nextNonceManager::next_nonce_at的非ce 分配BenchMediansign_trade_action42.0 µsrest_auth_headers40.9 µssigner_from_key31.6 µsabi_encode_trade236 nsnonce_next45.8 ns签名上下文常量ACTION_TYPEHASH、domain_separator_for(DeriveEnvironment::Mainnet)、trade_module_address_for(...)来自 src/signing 模块这些是与 Derive 链上合约绑定的一级常量也是后续Exec 为签名主导结论的输入前提。分发管道dispatch线上 WS 负载到执行事件dispatch组测量交易所 WS 负载DeriveOrdersSubscriptionData、DeriveTradesSubscriptionData经ExecutionEventEmitter发出事件的链路覆盖 解析 去重 身份查找 事件构造核心函数为 src/execution.rs 的dispatch_orders_payload/dispatch_trades_payloadorders_untracked转发原始状态报告未注册身份WsDispatchState为空orders_tracked解析注册身份并发出OrderAccepted事件状态中预注册alpha-strategy标签对应的OrderIdentitytrades_fill解析注册身份并发出OrderFilled事件BenchMedianThroughputdispatch/orders_untracked8.53 µs117 k/sdispatch/orders_tracked9.01 µs111 k/sdispatch/trades_fill8.45 µs118 k/s分发基准使用 Criterion 的iter_batched每次迭代都基于全新的WsDispatchStatesetup 闭包中重建不计时因此测到的是 解析 去重 身份查找 ExecutionEventEmitter发送。注意channel 发送会引入方差这组行比入站与执行组噪声更大。common::bench_emitter返回与 unbounded channel 绑定的 emitter基准在每次 setup 前调用drain清空接收端避免队列跨样本累积影响方差接收端必须保持存活否则send_order_event会退化为 warn 日志的空操作而扭曲测量。组件分解micros.rs定位时间花在哪里当入站或执行基准出现回归时micros.rs提供诊断性分解把管道数字拆成可比的组成部分decode_only原始字节 → 类型化消息的成本帧信封解码 频道from_value解码parse_only类型化消息 → Nautilus 域类型的成本与对应的decode_only相加应约等于data.rs的入站数字atom/*Decimal、Price、UUID4、TradeId 构造与分发状态churn 的原子成本BenchMediandecode_only/orderbook423 nsdecode_only/ticker1.56 µsparse_only/orderbook_deltas49.9 nsparse_only/trade32.2 nsparse_only/ticker_quote36.6 nsparse_only/order_report90.7 nsparse_only/fill_report109 nsatom/decimal_from_str6.97 nsatom/price_from_decimal_dp6.54 nsatom/price_combined12.3 nsatom/trade_id_new8.89 nsatom/uuid4_new12.9 nsatom/state_construct_primed4.11 µsatom/state_drop_primed1.13 µsatom/dedup_trade_hit11.6 nsparse_only/order_report与parse_only/fill_report对应 src/http/parse.rs 的parse_derive_order_to_report/parse_derive_trade_to_fill_report分解的是dispatch端到端执行的入站执行报告路径。关键性能结论五条可从源码验证的规律1. 入站解码规避了Value中间层src/websocket/messages.rs 中WsSubscriptionPayload.data以serde_json::value::RawValue原始 payload 字节持有而非解码后的Value帧层单趟解析为类型化结构捕获params.data为RawValue各频道解析器再直接把这些字节解码进各自的类型化结构。整个入站路径都不会把帧或庞大的data子树物化为serde_json::Value树。这一优化使每条入站行相比旧的Value解码方案大约减半如decode_only/ticker从 3.11 µs 降到 1.56 µsbook_deltas从 1.06 µs 降到 0.47 µs。2. 入站仍由解码主导decode_only占book_deltas约 90%473 ns 中的 423 ns占quotes约 95%1.64 µs 中的 1.56 µs。解析本身极快盘口增量解析低于 50 nsquote/trade 低于 40 nsDecimal、Price、UUID4、TradeId 构造全部低于 15 ns。这解释了为什么优化解析逻辑对入站整体收益有限——瓶颈在 JSON 解码本身。3. 四条 ticker 衍生行在生产中共用一次解码quotes、mark_price、index_price、funding_rate各自测量的是独立DeriveTickerMsg解码约 1.56 µs加一个低于 40 ns 的解析因此都落在约 1.6 µs。但生产环境中实时数据客户端只解码一次 ticker 帧再从这一条消息派生出全部四条流——把四行数字相加会重复计数。它们的共同杠杆是 ticker 解码而非各流各自的解析。4.option_greeks是最重的入站行期权 slim ticker 在共享 ticker 字段之外还携带option_pricing块delta/gamma/vega/theta/rho、隐含波动率、forward因此option_greeks以 2.35 µs 成为入站最重行见 benches/common/mod.rs 的TICKER_OPTIONfixture 说明。5. 执行路径签名绑定sign_trade_actionEIP-712ABI encode keccak secp256k1为 42.0 µs主导了submit_limit/submit_market/modify均约 42.1 µsABI encode236 ns与 JSON 序列化与之相比是噪声。cancel无需签名仅 46 ns。不改变签名方案的优化无法移动签名行的数字。rest_auth_headersEIP-191约 41 µs因为它执行的是同一次 secp256k1 签名。signer_from_key的 31.6 µs 私钥展开在客户端构造 signer 时执行一次按订单摊销不计入单笔成本。6. 稳态分发状态远便宜于逐次重建分发基准每次迭代重建WsDispatchState构造 4.11 µs drop 1.13 µs均不计时而生产状态长期存活稳态去重命中atom/dedup_trade_hit仅约 12 ns。因此生产分发的实际开销是解析 去重 身份查找 事件发送而不是状态 churn。何时刷新这份基准依据 BENCHMARKING.md 的 Recording results 规范当发生实质性性能变更或发布前应显式刷新本文件并更新测量日期。提交到 BENCHMARKING.md 的数字必须使用bench-ltoprofile 并记录测量上下文CPU 型号、内核/操作系统、Rust 工具链、构建 profile。若要进一步验证改动可将运行纳入 CI 的 CodSpeed CPU 模拟比较或用cargo bench的 Criterion 基线功能做本地背靠背对比涉及 Python 端 PyO3 调用成本时则应改用 Python 基准见 scripts/benchmark-backtest-versions.py 的驱动模式。对于希望深入 Derive 适配器实现细节的读者建议继续阅读入站解析实现 src/websocket/parse.rs、出站负载构建 src/http/query.rs、分发与身份解析 src/execution.rs、签名与 nonce 管理 src/signing以及基准输入所依赖的真实交易所抓包 test_data/perps 与 test_data/options。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NautilusTrader Derive 适配器基准测试深度解析：入站解码、签名与分发管道的性能剖析
NautilusTrader Derive 适配器基准测试深度解析入站解码、签名与分发管道的性能剖析【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader本文基于 crates/adapters/derive/benches/BENCHMARKS.md 展开系统讲解 NautilusTrader 中 Derive 交易适配器的四组 Criterion 基准测试套件data、exec、micros、signing其测量环境与复现方法、每条基准的语义定义、实测数据表以及源码层面的性能结论如RawValue单趟解码、EIP-712 签名主导执行路径等。读完本文你将掌握 Derive 适配器端到端热路径的成本分布能够在自己的机器上复现这套基准并用micros.rs组件分解快速定位管道性能回归的来源。基准测试定位文档即基线DeriveDerive.xyz是一个基于链上结算的衍生品交易所其 NautilusTrader 适配器位于 crates/adapters/derive核心 crate 名为nautilus-derive。适配器需要同时处理两套截然不同的工作负载一是高频的 WebSocket 行情入站流盘口增量、ticker、成交、资金费率、期权 Greeks 等二是每次下单都必须执行的链上签名路径EIP-712 订单签名 REST 请求鉴权。依据仓库根目录 BENCHMARKING.md 中基准即文档Benchmarks are documentation的原则本文件记录的是热路径的构成、实测输入与成本快照供后续优化和回归对照使用。文中所有数字均于 2026-05-30 在 AMD Ryzen Threadripper 9980X 上测得rustc 1.95.0bench-ltoprofilerelease 优化 lto fatcodegen-units 1且保留debug full调试符号。CPU governor 固定为performance并通过setarch -R关闭 ASLR套件先完整跑一遍以预热缓存、稳定时钟再进行正式测量——冷启动首次运行会令每行数字虚高约 10%。需要强调的是绝对数值因机器而异只有同机对比same-machine deltas才有意义。该文件的刷新时机为实质性性能变更时或发布前同时更新测量日期。如何复现环境控制与命令序列由于基准对 CPU 频率、ASLR、缓存与散热状态敏感复现必须遵循严格的环境控制流程# 1. 锁定 CPU 为 performance 调度器需要 root sudo cpupower frequency-set -g performance # 2. 关闭 ASLR 并执行预热运行结果不计入 setarch -R cargo bench -p nautilus-derive --profile bench-lto \ --bench data --bench exec --bench micros --bench signing # warm-up # 3. 正式测量 setarch -R cargo bench -p nautilus-derive --profile bench-lto \ --bench data --bench exec --bench micros --bench signing # measured # 4. 恢复默认 governor sudo cpupower frequency-set -g powersave # restore default--profile bench-lto与cargo bench默认的benchprofile 的关键区别在于bench-lto增加lto fat与codegen-units 1与生产 release 二进制保持一致因此发布到 BENCHMARKS.md 的基线数字必须使用 bench-lto详见 BENCHMARKING.md 的 Measurement requirements 一节。更完整的降噪策略见仓库根目录 BENCHMARKING.md。四个 bench 目标在 crates/adapters/derive/Cargo.toml 中注册harness false即使用 Criterion 自带 harness共享 benches/common/mod.rs 中的 fixture 与工具函数。入站 fixture 直接include_str!引入 test_data 下真实抓取的交易所数据在 bench 设置阶段由subscription_frame包装成线上投递的 JSON-RPC subscription 信封因此基准输入与解析器测试语料保持同步。入站管道data.rs原始 WS 字节到 Nautilus 域类型data.rs测量的是从原始 WebSocket 帧字节到 Nautilus 域类型的完整入站链路覆盖帧解码单趟解析为类型化帧 频道解码原始 payload 字节到类型化结构体 解析 Nautilus 类型构造。基准循环内无 I/O、无异步运行时、无 channel仅测纯 CPU 计算。各行的输入来自test_data的真实捕获benches/common/mod.rs 中fixtures模块定义了频道与数据book_deltasorderbook.ETH-PERP.1.10频道盘口快照增量ws_orderbook_eth.jsonquotes/mark_price/index_price/funding_rateticker_slim.ETH-PERP.1000频道perp slim tickerws_ticker_slim_eth.jsontradestrades.perp.ETH频道公开成交ws_trade_eth.jsonbarsREST OHLCV 路径http_public_candles_eth.json因为Derive 没有 WS K 线频道该行解码 candle 记录并构造Baroption_greeksticker_slim.ETH-20260627-3500-C.1000期权频道ws_ticker_slim_eth_call.json行序从最基础的行情流盘口增量向下经过 ticker 衍生流quotes/mark/index/funding/bars最后是期权专属的 Greeks 流BenchMedianThroughputinbound_pipeline/book_deltas473 ns2.12 M/sinbound_pipeline/quotes1.64 µs610 k/sinbound_pipeline/trades742 ns1.35 M/sinbound_pipeline/mark_price1.59 µs631 k/sinbound_pipeline/index_price1.59 µs631 k/sinbound_pipeline/funding_rate1.57 µs639 k/sinbound_pipeline/bars670 ns1.49 M/sinbound_pipeline/option_greeks2.35 µs426 k/s从源码看benches/data.rs每条基准都走同一条调用链DeriveWsFrame::parse帧层→ 频道解析如parse_orderbook_msg/parse_ticker_msg/parse_trades_msg→ 域解析parse_orderbook_deltas、parse_ticker_quote、parse_trade_tick、parse_candle_record、parse_option_greeks等均位于 src/websocket/parse.rs。价格与数量精度由 ETH-PERP 合约属性决定PRICE_PRECISION 2tick_size 0.01、SIZE_PRECISION 3amount_step 0.001。执行管道exec.rs策略命令到待发送的线上字节exec_pipeline测量从策略命令OrderAny/ cancel到可发送的线上字节的整条出站路径submit_limit/submit_market/modify覆盖签名路径private/order与private/replace完整流程为 normalize订单归一化→ ABI encode → EIP-712 签名 → JSON 序列化。submit_market额外携带限价保护参数Some(dec!(3500))cancel覆盖无签名路径private/cancel构建参数 序列化Derive 只支持 Limit 与 Market 两种订单类型因此没有止损单stop-order基准行。BenchMedianThroughputexec_pipeline/submit_limit42.1 µs23.8 k/sexec_pipeline/submit_market42.1 µs23.7 k/sexec_pipeline/modify42.1 µs23.7 k/sexec_pipeline/cancel45.8 ns21.8 M/s出站负载构造由 src/http/query.rs 的order_to_derive_payload/order_replace_to_derive_payload完成。基准中使用的签名上下文SESSION_KEY、钱包地址、SUBACCOUNT_ID 30769、EXPIRY_SEC取远未来时间戳以通过 EIP-712 过期守卫定义了签名基准的固定输入。签名基准signing.rsEIP-712 与 EIP-191 的成本解剖signing.rs把执行路径中最昂贵的部件单独抽出来测sign_trade_actionEIP-712 订单签名ABI encode keccak secp256k1每笔订单提交支付一次。基准构造SignedAction::new后调用action.sign(signer)rest_auth_headersEIP-191 时间戳签名build_rest_auth_headers_at每个 HTTP 读请求支付一次signer_from_keysecp256k1 私钥展开PrivateKeySigner::from_str客户端启动时支付一次abi_encode_tradeTradeModuleData的 ABI 编码签名前的一小步nonce_nextNonceManager::next_nonce_at的非ce 分配BenchMediansign_trade_action42.0 µsrest_auth_headers40.9 µssigner_from_key31.6 µsabi_encode_trade236 nsnonce_next45.8 ns签名上下文常量ACTION_TYPEHASH、domain_separator_for(DeriveEnvironment::Mainnet)、trade_module_address_for(...)来自 src/signing 模块这些是与 Derive 链上合约绑定的一级常量也是后续Exec 为签名主导结论的输入前提。分发管道dispatch线上 WS 负载到执行事件dispatch组测量交易所 WS 负载DeriveOrdersSubscriptionData、DeriveTradesSubscriptionData经ExecutionEventEmitter发出事件的链路覆盖 解析 去重 身份查找 事件构造核心函数为 src/execution.rs 的dispatch_orders_payload/dispatch_trades_payloadorders_untracked转发原始状态报告未注册身份WsDispatchState为空orders_tracked解析注册身份并发出OrderAccepted事件状态中预注册alpha-strategy标签对应的OrderIdentitytrades_fill解析注册身份并发出OrderFilled事件BenchMedianThroughputdispatch/orders_untracked8.53 µs117 k/sdispatch/orders_tracked9.01 µs111 k/sdispatch/trades_fill8.45 µs118 k/s分发基准使用 Criterion 的iter_batched每次迭代都基于全新的WsDispatchStatesetup 闭包中重建不计时因此测到的是 解析 去重 身份查找 ExecutionEventEmitter发送。注意channel 发送会引入方差这组行比入站与执行组噪声更大。common::bench_emitter返回与 unbounded channel 绑定的 emitter基准在每次 setup 前调用drain清空接收端避免队列跨样本累积影响方差接收端必须保持存活否则send_order_event会退化为 warn 日志的空操作而扭曲测量。组件分解micros.rs定位时间花在哪里当入站或执行基准出现回归时micros.rs提供诊断性分解把管道数字拆成可比的组成部分decode_only原始字节 → 类型化消息的成本帧信封解码 频道from_value解码parse_only类型化消息 → Nautilus 域类型的成本与对应的decode_only相加应约等于data.rs的入站数字atom/*Decimal、Price、UUID4、TradeId 构造与分发状态churn 的原子成本BenchMediandecode_only/orderbook423 nsdecode_only/ticker1.56 µsparse_only/orderbook_deltas49.9 nsparse_only/trade32.2 nsparse_only/ticker_quote36.6 nsparse_only/order_report90.7 nsparse_only/fill_report109 nsatom/decimal_from_str6.97 nsatom/price_from_decimal_dp6.54 nsatom/price_combined12.3 nsatom/trade_id_new8.89 nsatom/uuid4_new12.9 nsatom/state_construct_primed4.11 µsatom/state_drop_primed1.13 µsatom/dedup_trade_hit11.6 nsparse_only/order_report与parse_only/fill_report对应 src/http/parse.rs 的parse_derive_order_to_report/parse_derive_trade_to_fill_report分解的是dispatch端到端执行的入站执行报告路径。关键性能结论五条可从源码验证的规律1. 入站解码规避了Value中间层src/websocket/messages.rs 中WsSubscriptionPayload.data以serde_json::value::RawValue原始 payload 字节持有而非解码后的Value帧层单趟解析为类型化结构捕获params.data为RawValue各频道解析器再直接把这些字节解码进各自的类型化结构。整个入站路径都不会把帧或庞大的data子树物化为serde_json::Value树。这一优化使每条入站行相比旧的Value解码方案大约减半如decode_only/ticker从 3.11 µs 降到 1.56 µsbook_deltas从 1.06 µs 降到 0.47 µs。2. 入站仍由解码主导decode_only占book_deltas约 90%473 ns 中的 423 ns占quotes约 95%1.64 µs 中的 1.56 µs。解析本身极快盘口增量解析低于 50 nsquote/trade 低于 40 nsDecimal、Price、UUID4、TradeId 构造全部低于 15 ns。这解释了为什么优化解析逻辑对入站整体收益有限——瓶颈在 JSON 解码本身。3. 四条 ticker 衍生行在生产中共用一次解码quotes、mark_price、index_price、funding_rate各自测量的是独立DeriveTickerMsg解码约 1.56 µs加一个低于 40 ns 的解析因此都落在约 1.6 µs。但生产环境中实时数据客户端只解码一次 ticker 帧再从这一条消息派生出全部四条流——把四行数字相加会重复计数。它们的共同杠杆是 ticker 解码而非各流各自的解析。4.option_greeks是最重的入站行期权 slim ticker 在共享 ticker 字段之外还携带option_pricing块delta/gamma/vega/theta/rho、隐含波动率、forward因此option_greeks以 2.35 µs 成为入站最重行见 benches/common/mod.rs 的TICKER_OPTIONfixture 说明。5. 执行路径签名绑定sign_trade_actionEIP-712ABI encode keccak secp256k1为 42.0 µs主导了submit_limit/submit_market/modify均约 42.1 µsABI encode236 ns与 JSON 序列化与之相比是噪声。cancel无需签名仅 46 ns。不改变签名方案的优化无法移动签名行的数字。rest_auth_headersEIP-191约 41 µs因为它执行的是同一次 secp256k1 签名。signer_from_key的 31.6 µs 私钥展开在客户端构造 signer 时执行一次按订单摊销不计入单笔成本。6. 稳态分发状态远便宜于逐次重建分发基准每次迭代重建WsDispatchState构造 4.11 µs drop 1.13 µs均不计时而生产状态长期存活稳态去重命中atom/dedup_trade_hit仅约 12 ns。因此生产分发的实际开销是解析 去重 身份查找 事件发送而不是状态 churn。何时刷新这份基准依据 BENCHMARKING.md 的 Recording results 规范当发生实质性性能变更或发布前应显式刷新本文件并更新测量日期。提交到 BENCHMARKING.md 的数字必须使用bench-ltoprofile 并记录测量上下文CPU 型号、内核/操作系统、Rust 工具链、构建 profile。若要进一步验证改动可将运行纳入 CI 的 CodSpeed CPU 模拟比较或用cargo bench的 Criterion 基线功能做本地背靠背对比涉及 Python 端 PyO3 调用成本时则应改用 Python 基准见 scripts/benchmark-backtest-versions.py 的驱动模式。对于希望深入 Derive 适配器实现细节的读者建议继续阅读入站解析实现 src/websocket/parse.rs、出站负载构建 src/http/query.rs、分发与身份解析 src/execution.rs、签名与 nonce 管理 src/signing以及基准输入所依赖的真实交易所抓包 test_data/perps 与 test_data/options。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考