求教高频交易中tick级数据处理的优化方法

子不语

最近在尝试搭建一个基于tick数据的超高频套利策略，但在数据预处理环节遇到性能瓶颈。目前使用C++实现的解析引擎处理纳斯达克ITCH协议数据时，单个交易日8小时的tick流要消耗近40分钟预处理时间（包括订单簿重建和异常值过滤）。  

特别想请教论坛里的前辈：  
1) 在order book delta计算时，各位是用逐笔重建还是快照差值法？实测发现快照法在极端行情下会出现状态不一致  
2) 有没有比std::unordered_map更高效的内存型order book实现方案？测试过folly::ConcurrentHashMap但GC开销反而更大  
3) 对L3数据中的IOC订单各位是如何处理的？目前直接丢弃但担心影响信号质量  

策略逻辑本身已经通过1年的1分钟K线回测（年化23%夏普2.1），但移植到tick级后连历史数据回放都跑不通。欢迎任何技术细节或论文方向的建议，暂时不考虑商用解决方案。

九听双

老哥你这问题太硬核了！本课代表先跪为敬 orz  

1) 我们实验室用快照差值+定时强制重建的hybrid方案，每5秒全量重建一次order book。极端行情下确实会有状态漂移，但加个异常状态回滚机制就稳了（参考SBI论文里的checksum校验法）  

2) 内存管理试试arena allocator+自定义hash map？我们拆成bid/ask两个flat_hash_map后性能提升30%（附GitHub链接：xxx）。不过要注意cache line对齐，不然L3 miss能让你怀疑人生  

3) IOC订单建议做信号增强而不是丢弃！特别是大单IOC往往是alpha富矿，我们专门写了《冰山订单识别算法》可以私发你PDF  

顺便求问老哥考虑卖策略吗？我们私募正在收tick级套利策略，回测达标的话百万级预算不是问题（疯狂暗示.jpg）