Backtest / Optimise – Tortuously SLOW!?

Forums › ProRealTime English forum › ProRealTime platform support › Backtest / Optimise – Tortuously SLOW!?

  • This topic has 15 replies, 5 voices, and was last updated 6 years ago by avatarLeo.
Viewing 15 posts - 1 through 15 (of 16 total)
1 2
  • 03/03/2018 at 10:53 PM #64330
    GraHal

    Is it just me or has backtest / optimise become so slow now that it is virtually unusable over anything more than 25,000 bars?

    I am talking about optimising 1 variable at a time and about 30 lines of code in total with no ‘Calls’! 🙁

    GraHal

    03/04/2018 at 10:34 AM #64344
    Juan Salas

    Hi Grahal,

    I regularly optimise a simple strategy without “CALL”, two variables with values between 1 to 80 and it takes an average of 1 hour for a 20.000 bars.

    If I try something bigger you can forget about it. It is not sustainable.

     

    1 user thanked author for this post.
    avatar GraHal
    03/04/2018 at 2:45 PM #64360
    GraHal

    Seems like dead stop now!?

    I’ve just been changing variable values myself and re-running the backtest then repeat  … and that is on 10,000 bars!

    How are you all managing or is it just me again??? 🙂

    I’ve closed My Platform, I’ll try again later and I’ll also try the same gig on the Demo Platform.

    I’ll let you know!

    GraHal

    03/05/2018 at 6:33 PM #64479
    Ulrike

    Hello,

    Please note that the optimization tool runs on our servers and results are then sent back to your computer.

    You may also use bigger intervals in the beginning and then decrease the step interval in a second run for fine-tuning.

    Regards,

    Ulrike

    03/05/2018 at 6:40 PM #64480
    GraHal

    Is that a recent change  @Ulrike?

    We have always been lead to believe that optimisation / backtests run on the PRT Servers?

    Thanks
    GraHal

    PS I do use bigger intervals then smaller intervals etc, but thanks for the reminder! 🙂

    03/05/2018 at 7:16 PM #64484
    Ulrike

    Backtests are running indeed on servers.

    However, the optimization tool runs on your computer and needs to communicate permanently with the server. Therefore, if you have for example temporarily a poor upload speed or micro-interruptions the calculation may take more time then usual.

    I assume that you have a cabled-wired connection to the Internet?

    03/05/2018 at 7:27 PM #64491
    GraHal

    Yes I have fibre broadband to my nearest roadside cabinet (few hundred metres away) and then cable from the cabinet to my house.

    03/05/2018 at 7:32 PM #64492
    Ulrike

    And in your house? Do you use Wifi or Ethernet cable?

    03/05/2018 at 7:36 PM #64493
    verdi55

    I regulary do optimizations on 200.000 bars, 800 code lines and 50-100 parameter variations. It takes about 30 min in general, which is totally acceptable for me.

    03/05/2018 at 9:23 PM #64501
    GraHal

    ethernet cable from my PC to the router

    03/05/2018 at 11:48 PM #64517
    Juan Salas

    I think we should measure the rapidness of the optimisation by the number of combinations. Regardless number of variables, and step, for me, doing around 5000 out of 100000 combinations, it takes 1 hour.

    03/06/2018 at 12:14 AM #64521
    GraHal

    I agree Juan, we do need an agreed yardstick to measure Optimising elapsed time.

    Do you mean 5000 combinations in the box highlighted by red arrow on attached takes about 1 Hour?

    @verdi55 please tell us how many combos (combinations) takes you about 30 mins? Please could you time it next time?

    If we time our combos (to nearest minute?) and post on here then maybe we can work out an average time per 100 combos??

    Users can then judge if they really do have a problem with PC or internet connection or code complexity or whatever??

    Thank You for a Good Idea @Juan Salas
    GraHal

     

    03/06/2018 at 12:48 AM #64523
    verdi55

    As I said, 50-100 combinations (variation of only one single parameter). This is a pretty complex system, but I do not feel that optimization speed has decreased over the past 2 years, I’d rather say it has become better.

    To measure time per combination makes little sense, I think, because the complexity of If-then loops may be vastly different.

    I nominally have 50 Mbit/s internet speed which I truly get most of the time.

    03/06/2018 at 10:37 AM #64558
    GraHal

    I feel it would give a broad brush to get a feel for the different speeds we are getting?

    We could then move on to, for example, me asking you to run an optimise on an Algo of mine that took forever on mine so I can see how long it takes on your superfast highway? 🙂

    Above is more constructive than us all moaning, or feeling jealous that you’ve got something we haven’t verdi55? 🙂

    (I am not being facetious or emotive, so please forgive my English humour  … I just try to make readers smile! :) )

    I think a measure to start with could be …

    Variable Combos x No of Bars in 1000’s x Code Complexity (on 1 to 3 scale, 3 most complex) / Time in Mins

    So to use an example …

    100 combos x 10K  bars x 1 for the code / 30 = 33K opto-iterations per minute

    GraHal

     

    03/06/2018 at 10:51 AM #64564
    Juan Salas

    Hi Grahal,

    Yes, your pic with the red arrow marks exactly what I meant.

    I have taken the 5000/100000 as 1 hour time. So, if I want something faster, I know I will have to remove variables or increase the steps.

     

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 16 total)
1 2

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
prt backtest in demo is very slow

Create your free account now and post your request to benefit from the help of the community
Register or Login