Vespa314/chan.py

trigger_load耗时问题请教

Closed this issue · 10 comments

AlexYY0 commented

image
请问我这里是使用有问题还是怎么回事，刚开始执行一次是0.01s。后续这个执行时间一直在增长。频率5m和30m
当前Bar:2020-01-02 09:35:00,耗时: 0.00秒
当前Bar:2020-01-02 09:40:00,耗时: 0.00秒
...
当前Bar:2020-03-31 14:25:00,耗时: 0.77秒

AlexYY0 commented

还在增长，一次计算已经超过1s了，本来想init算一下2年的数据，看起来似乎不可行。 @Vespa314 大佬是这样的吗

Vespa314 commented

如果是copy.deepcopy，那符合预期，因为这个计算是全量的；

AlexYY0 commented

如果是copy.deepcopy，那符合预期，因为这个计算是全量的；

我刚刚又试了一下，没有copy.deepcopy，30m再计算一次，5m的list先暂时累加，从2020-01-01到2021，现在依旧很多接近1s或超过1s了，达到了1.2s

AlexYY0 commented

如果是copy.deepcopy，那符合预期，因为这个计算是全量的；

5m的数据，一年大概1w多一点的数据，如果是多维度的，就更耗时了。我试了一下，单维度的，即使是5m的，耗时还没这么明显，多维度就不行了

Vespa314 commented

大致定位到原因了，近期抽空会优化一下；

  • 👍1
Vespa314 commented

pull一下新代码试试；

  • 👍1
AlexYY0 commented

pull一下新代码试试；

可以，现在确实速度快了很多：
4年单维度的5m：0.05s左右(以前>0.1s)
4年多维度的5m和30m(没有copy的情况下)：0.2s左右(以前>1s)

Vespa314 commented

量少的话和以前差别不大，上万根 K 线后差别就明显很多了；

本质是以前 O(N^2)复杂度，现在近似于 O(1)

AlexYY0 commented

量少的话和以前差别不大，上万根 K 线后差别就明显很多了；

本质是以前 O(N^2)复杂度，现在近似于 O(1)

我看到代码变更里的update_zs_in_seg方法：变成了for zs in zs_list[::-1]:，原来是正序，现在是倒叙，那么seg.add_zs(zs)，这里是否会有影响，我看有些地方使用了seg.zs_lst[-1]，是否要修改为反过来seg.zs_lst[0] @Vespa314

  • 👍1
Vespa314 commented

感谢提醒，fixed！