Persistence of Global Variables

 

I rarely use Global Variables - https://docs.mql4.com/globals - and recently became interested in them for their ability to persist across optimization runs in Strategy Tester.

My question is regarding the persistence of global variables - do they live on after strategy tester ends the optimization? If a global variable is created during backtesting does it persist even if the MT4 platform has been shutdown and subsequently restarted?

The documentation regarding global variable persistence says they will exist for up to 4 weeks after the most recent access. So I could create a global variable today, shutdown my computer, come back in 3 weeks, boot up my computer and re-launch MT4 and my global variable will still exist and have the same value that I last left it as having?

 
1005phillip wrote >>

I rarely use Global Variables - https://docs.mql4.com/globals - and recently became interested in them for their ability to persist across optimization runs in Strategy Tester.

My question is regarding the persistence of global variables - do they live on after strategy tester ends the optimization? If a global variable is created during backtesting does it persist even if the MT4 platform has been shutdown and subsequently restarted?

The documentation regarding global variable persistence says they will exist for up to 4 weeks after the most recent access. So I could create a global variable today, shutdown my computer, come back in 3 weeks, boot up my computer and re-launch MT4 and my global variable will still exist and have the same value that I last left it as having?


3 weeks i was not trying, but after few days was there.

Take care with backtest if you access and change the same global variable like you use in live/demo account....

 

Ah, I see they store the global variables to the hard-drive when MT4 is shutdown.

It's in TerminalPath()+"\profiles\gvariables.dat"

 
1005phillip:

It's in TerminalPath()+"\profiles\gvariables.dat"

Note EADeveloper's important comment - the Tester and the Terminal share the SAME GV's (a bad design choice by MQ) - make sure leftover GV's from the Tester do not cause problems if u start Live trading. Also - if these GV's are vital to the EA, then some sort of persistence layer should be added (for example - emailing the gvariables.dat as an attachment to yourself occasionally, etc.).

 

Hi gordon, thanks for highlighting this "feature" as I'm sure it has come to bite many coders in the past. I can see where there is great potential to have things go very badly.

I personally have a protocol of never running backtests in MT4 instances that are also tasked with live or forward-demo trading. It's my failsafe to safeguard against the uncountable ways I can screw up my trading. Globalvariables being only the most recently discovered area of ignorance on my behalf.

It is really really really odd to me that metaquotes went to such lengths to partition and isolate backtesting domains by way of the simulated server/terminal environment and yet they allowed something like globalvariables to be able to "tunnel" through the barrier.

At any rate, at least throwing if(IsOptimization()) and if(IsOptimization()==false) in front of the globalvariable check/set/get/del actions enables me to delineate between backtesting versions and live trade versions of the globalvariables. It adds to code bulk of course.

 
gordon:

..... Also - if these GV's are vital to the EA, then some sort of persistence layer should be added (for example - emailing the gvariables.dat as an attachment to yourself occasionally, etc.).

Hi guys,
That's a good idea gordon. A couple of questions:
Would writing to a .txt or .csv file be faster? If we need a safe place where data can be persistent email server is a great bet, but how would we read it? I'm assuming we need to download & overwrite the existing .dat ?

 
cameofx:

Would writing to a .txt or .csv file be faster? If we need a safe place where data can be persistent email server is a great bet, but how would we read it? I'm assuming we need to download & overwrite the existing .dat ?

That was just an example... Personally I use a flat csv for persistence (but only when there's no choice... many EA's can be designed to be self-persistent). The simple solution is to manually copy the persistence files and start the Terminal, but that only needs to be done if we continue a session from a different computer... The most common failures would be an OS crash/restart (BSOD) or a HW related restart - in these cases the persistence files are already there. So either manually start the Terminal or make it automatically start with Windows (there are pros and cons to each). More complex solutions would be to have the EA automatically get the persistence info from an online database, etc...


There's a good discussion about persistence layer design here -> https://www.mql5.com/en/forum/119716.

 
Thank you for these insights & link gordon, made a lot of sense.
Reason: