Performance of certain ProOrder commands/functions/constants
- This topic has 4 replies, 2 voices, and was last updated 2 years ago by
.
-
This topic is deliberately in the Platform Support section, so PRT support may read it (they monitor this section) and do something with it ?
Waiting hours for an Algo to finish optimising only to find that the coded strategy is flawed is not my idea of fun!
Tell me about it! I usually play computer chess while waiting and I can tell you my game is getting damn good just from the hours I put in.
Dear people,
As a life time performance specialist, I may observe “performance issues” by nature. That this same life ever back started with writing a chess program is hardly related, though it still was because chess is time related indeed (per move). So the smarter all was, the more looking-ahead depth could be achieved.
Today I am handicapped by the commands which just outright kill you for waiting on the backtests / optimising. And thus I don’t use them – or at least try to avoid most of it.
Hopefully this helps some of you, and more-hopefully PRT can do something about it. Possibly others know commands to avoid as well.Here we go in random sequence (and possibly later I myself may think of more – I will add them in next posts) :
- Program length.
This is obvious (the more code to execute the longer it takes to deal with one bar = one call of the program). Notice however, that program length aggressively adds to the throughput time of backtests. In my view this should be linear, but it really is not. - Graph commands.
Everybody will know this, but what most don’t know or refuse to accept is that the PRT graphing comes with so-called memory leaks; the longer you backtest, the more the chance that the lot runs stuck. Thus indeed, the graphing is slow, but it is also buggy and this makes it unusable for the larger backtests (1M). This combines with other problematic commands. See second one below.
Btw, I use If Condition <> Condition[1] then – Graph XYZ – endif in the hope that it helps (it should) but saw no proof of that. - The Volume “constant”. This is the most impeding function I know about. Using that and all becomes infinitely more slow. Notice that this relates to the number of bars the volume is taken from (more than 2 and things start to collapse).
- The Volume constant in combination with a Graph command. This makes the lot error out for me BUT this is again related to the program size (with a small size there are no issues at all with this combination).
Ever seen a graph not accepting colors (it stays white) ? then from now on you know what’s going on : the code can’t cope with too much at the same time (to me it seems that then the Coloured clause is being ignored).
What is special about observing the behaviour around Volume, is that I suspect that this is a server-side performance (like memory) issue. I can run backtests at night, while I can’t during the day. To me this tells that the server may be trashing somewhere. - ExponentialAverage.
This with the notice that I hardly use these functions anyway (only MovingAverage) so this issue could be about more types of them. If I replace one MovingAverage with an ExponentialAverage, any backtest takes twice as long. Notice the emphasis on “one”, because it could be about one out of 20 – that one making all take twice as long. That severe it is. - Active Graph commands during Forward Testing. So notice that this does not graph a thing, but that it holds up largely anyway.
Putting an If (false) around them helps adequately. This of course by means of a global variable (I use several Grph variables for it, so I can included certain sets). - GraphOnPrice is even more killing, but this is a kind of logical.
- Imply many trades.
Yes, if anything is daft, it is this one; The more trades you imply, the slower all becomes. To me this is logic again, but it is good to know anyway (at least for PRT development people). And oh, in my case this is about ~500 trades per month easily. And since a backtest of 1M candles is a month in my case, we now know the context. - Apply too many combinations of optimisation variables.
One variable with a result of say 100 situations is fine, but 10 variables with 10 outcomes each (which also leads to 100) may easily take 10 times longer. This again becomes aggressively more long when combine with e.g. Volume. Thus, using Volume with one variable may take 1 minute, but with 10 variables 1 hour. Something like that (and something is clearly not right in there). - Keep on typing in the editor when you can see it starts to struggle with echoing your keypresses. Stop – don’t wait for the dreaded message that “your last action requires more memory”, Save and restart PRT the soonest. A similar indication is the stuttering progressbar during the backtest (even if only once in a while). It *will* finish badly soon.
- Before GraHal has to mention it once again, he tells that there’s something about having too many systems (programs) readily available (to choose from) and I think he is right, but I could never really prove it.
- Use the IG servers.
Yes, you heard well. On the IG platform it is incredibly more slow (I do IB as well). My estimate : 5-10 times. Really. In combination with the “more trades” this becomes very apparent, and it is my idea that IG needs to use an additional layer to mimic stuff, where IB can work more directly. Or an other suspect : IG manipulates the price at the micro level (tick level), which IB does not. Btw, for Volume I expect the problem to be in the same realm, because Volume officially is not available to PRT-IG and it is calculated redundantly (don’t take my word for this latter – I only heard that from PRT support who seem to be clueless about these performance issues anyway).
This list is rather short, but do notice that if one of these little rules is ignored (the number of trades we obviously can’t help) a backtest may take 15-30 minutes for me, while it also can do it in 1 minute if I follow these rules nicely.
This is all so super-crucial that if I do obey these rules I can apply something like 100+ backtests in a weekend, while disobeying them would allow for what ? … less than 10 ? this would be unworkable for me.Thus, I hope this helps someone. But if others can add to this little list, we all may benefit.
1 user thanked author for this post.
Thanks Peter. I share your frustration : PRT Backtest is VERY slow when the code isn’t simple. The only solution I found is to save, quit and restart the plateforme before a new big simulation. Also, it’s killing me when you have the message that PRT will QUIT in 15min while you’re 75% progress in your backtest. We should be able to save and continue.
I’m also with IG (France) and they told me the VOLUME is the actual volume of IG clients worldwide. Can’t obviously check this information.
Another point, sometimes, when I clic on the last result of the backtest, the Dashboard shows information “Gain” for example different from the one I see on the backtest table. Sometimes, it’s slightly different, sometimes it’s exactly 2x.
Last but not least, on a few Algos, the backtest goes well and you have the same result over and over again, meaning the code is stable. But when I run it LIVE I receive a message something like “there are not enough bars to calculate certain indicators” despite the fact that I put PRELOADBARS=10k just before going live. And besides, I never use more than [200]. I read somewhere on this forum that this error message might be misleading as the source of error is not necessarily the number of bars, but the calculation of certain indicators or division by zero. So, it would be good that PRT indicates precisely what’s the problem and on which line, and still why does it work fine on backtest and doesn’t work live?
I’m running PRT on MacBook with M1, RAM 16 Go and 200 Go free disk space, and launching the PRT LIVE and PRT DEMO at the same time is a real nightmare. I think there is a problem with Java memory management.
Not sure if these problems exist on MT4/MT5, etc., But, I invested so much time learning PRT that I don’t see myself going again through the same learning journey with another language. So I want to keep PRT and I also want PRT to take our issues seriously.
Can you run Algos on PRT/IB? (PRT in France told me NO, Algos only available with IG)
1 user thanked author for this post.
Can you run Algos on PRT/IB? (PRT in France told me NO, Algos only available with IG)
Nope. Only Backtesting and Demo work for IB. But they keep on promising it. N.b.: I did all the major development within the IB environment waiting for Autotrading to be allowed with IB. Last May (2021) I kind of gave up, and it took me 6 months to rewrite all for IG. This is mainly because of different behavior at least on Forex (I think I said elsewhere that IG “manipulates” at the micro level – not necessarily meant negative, but averages work out totally different). Also working with spread complicates vastly (IB only uses commission (Broker Fee) apart from some very minor (ignorable) spread.
launching the PRT LIVE and PRT DEMO at the same time is a real nightmare.
Hmm … I can’t be 100% sure, but I can’t load two instances at the same time because the one will kill the other at the moment no first chart is visible of a first launched instance. However, an IB instance is completely separate from an IG instance, and those load perfectly together without any notice that one holds up the other. I should add that I have a processor which should up up to the task. What you see below is with two PRT-IB instances and a total of 40 or so charts on-screen. Notice, however, that this is mostly pre-market (ETH) USA (regardless of charts regular hours imply way more cpu usage because of refreshing lists enormously more).
May it help : what I noticed and noted elsewhere in this forum, is that a single instance may take ages to load, proven by the system of my son next to me and by my own system elsewhere – both carrying the same processor (don’t know by heart which). Others tend to complain about startup times similarly and this is in the realm of several minutes. The ~40-chart system on my main PC loads under 15 seconds …More free disk space (once sufficient) really does not matter.
Oversized memory also does not matter because it is the PRT instance within itself which chokes. In the second attachment you see 3 instances with all “normal behaved” memory. But with BackTesting it will grow and grow and grow, and depending on other matters like program size, you may have a couple of runs only before it reaches 6GB and then it’s done. I created a topic somewhere which I may be able to find back. It is good for reference and knowing/learning when you’re still good to proceed or when to restart. And indeed, don’t run into the 18 hour limit by accident.1 user thanked author for this post.
- Program length.
Find exclusive trading pro-tools on 
