Looking at this from the other side, why does it take 1 hour to do the back-test!.
- Are you running near the maximum possible combinations with the number of variables and/or wide value ranges and small step values.
- Is the number of bars you back-testing over massive.
- Do I really know what I’m trying to back-test, and does it make sense.
- Is the code wrote in an efficient manner.
Best to start optimising the code.
If you can make the code more efficient, that will ripple though to every combination tested by the back-test.
I once had a code segment which needed to execute 4000 lines, per bar, to get a result, once modified I got it down to 40, big saving.
Running the code in real time may not affect the operation of the code whichever way its been wrote, but can make a massive difference when back-testing.
One of the big time waster’s is a loop.
- can you accumulate data values per bar, rather than loop back.
- if looping, reduce loop iterations with priority, and CONTINUE and BREAK
Another is the CALL instruction.
- Can you embed relevant instruction in CALL file into main file
Don’t run though code that’s not currently relevant.
- why check for a condition when at the time it doesn’t matter if its true or false.
At the end of the day it only cost time to optimise the code, and anything you learn can be used next time and built on and built in.
Anyway just a few thoughts.
2 users thanked author for this post.