Well improving the performance of my algo has been a success. My benchmark used to run in 16.7 minutes, and now it runs in 1.75 minutes. This is single threaded for both so havent even touched multithreading improvements which should be doable as well.
@mur2501 yes
@freemo
That's good ![]()
@freemo Optimizing ftw!
@freemo nice. optimization in Python is often weird. a lot of it for me is reducing unexpectedly costly attribute access. still occasionally find weird issues like a 'not in' being 50% slower than an 'in'
@freemo i should say, that's for a hash set. so the cost of the 'not' should be the only diff
@2ck Yea, normally I can get pretty close to optimal before i actually do performance profiling. But with python I was way off, things that normally would have virtually no cost to it seemed to be quite expensive for me. In the end I relied on the profiler more than an algorithmic understanding to fix it, which I dont like to do but I kinda had to in this case. In the end it worked though, its now fast enough that I can backtest a year worth of day trading in just a few minutes.
Your description of what you find yourself doing when you optimized seemed to match my own expiernce. which makes sense since in python an attribute/property may actually be a method so it really doesnt tell you much about if reading it is atomic or not. But the collections were also a damn mess and really hard to tell what algo backed the various collections I was using since they mostly came from third-party libs. a good example of this being numpy series which seemed to be any of several collection types backing it and the constructor was rather convoluted.
@freemo
in python?