Actual Computer Time During Testing

 
Im trying to find a way to get the actual realtime computer time while testing. TimeLocal() does this when the EA is attached to a chart but as it says in the manual, during testing computer time is modeled and equal the the server time. The reason I want this is to measure realtime backtesting rate (time interval tested / real time elapsed). Im pretty sure this resolves to #import-ing a windows dll that contains a function that gets this info then calling that function in the EA but my windows programming knowledge is 98% limited. Anyone know the name of such a windows file/function, or perhaps a simpler way?
 

I fail to see how this would help maybe you can enlighten me. Tho I only know little mql4 only, wouldn't server time be a constant shift to local time?

 

https://www.mql5.com/en/forum/106240

gets local & UTC time in datetime form, calling Windows DLLs

 
ubzen:

wouldn't server time be a constant shift to local time?


It would when you're not testing.. putting relativistic arguments aside, time runs at the same rate everywhere. But obviously the time modeled within the backtest runs much faster than realtime and for all practical purposes the two are unrelated.

The reason I want to know this information is simply to optimize the code in my EA, which as become quite dense in logic and seems a bit sluggish in backtesting.. plus, it would simply be interesting to me and attempting to optimize code will build my skills as a programmer.

 
brewmanz:

https://www.mql5.com/en/forum/106240

gets local & UTC time in datetime form, calling Windows DLLs


Exactly what I needed. Thank you!
 

Thats really nice codes provided by brewmanz.

@supertrade: can you give me a simple example when knowing the local time during a back-test would be helpful?

For example, if I wanted to Trade at 5 oClock Local Time. The Server is Gmt and I'm Gmt+5.

Couldn't I just say if(TimeCurrent()+5-hours)=5 oClock; ? And Vice-Versa, just +5hours from Server time to get the local time Something happened? Reason I'm asking is because I see allot of people asking for local time lately on this forum. If however you're saying you may Not know the shift then that's a different issue altogether.

I agree with you from a "learning to become a well rounded programmer" stand point.

From the "which as become quite dense in logic and seems a bit sluggish in backtesting" I'll dis-agree that this would help. It's my opinion, the more codes you add to mql4 the more dense and sluggish_in_backtesting it's going to perform.

 

This is actual code I use

datetime gdtWallTimeStart;
//+------------------------------------------------------------------+
//| expert initialization function                                   |
//+------------------------------------------------------------------+
int init()
{
   gdtWallTimeStart = GetWinLocalDateTime();
//----
   OrderProcessing.Init();
   OrderProcessing.DumpInfo();
//----
   gnBarsProcessed=0;
   gnTicksProcessed=0;
   return(0);
}
//+------------------------------------------------------------------+
//| expert deinitialization function                                 |
//+------------------------------------------------------------------+
int deinit()
{
   datetime dtWallTimeEnd = GetWinLocalDateTime();
   int nElapsedSecs = dtWallTimeEnd - gdtWallTimeStart;
//----
   Print("Processed: Bars=", gnBarsProcessed, ", Ticks=", gnTicksProcessed, " in ", nElapsedSecs, " secs");
   return(0);
}

to see how 'efficient' my EA is (ticks and bars per second of wall time). Then I can see the effect of how optimising works

 

@brewmanz, oh! thats a nice trick thanks for the tip.

3-Questions comes to my mind.

1) If you're using Optimizer, wouldn't the # of parameters effect the results?

2) I assume these functions OrderProcessing.DumpInfo(); dump info into file?

3) Do you save the # of parameters and steps somewhere so that you're making a fair comparison?

Boy, I learn something everyday from you gifted programmers. Thanks in Advance.

 

@ubzen, I think you may be misunderstanding.. the local time and server time are ALWAYS related by a simple shift. But that relationship become meaningless when you're backtesting and comparing the modelled server time (given by TimeCurrent() ) and the actual, real, time that you see when you look at your watch.

For example, Im running a backtest from March 25 2010 - today, when I press start it say 12:00pm on my watch, then when the test is over my watch says 12:05pm, meanwhile the modeled server time within the scope of the backtest runs through an entire year second by second. Clearly, the server time in the backtest and the time on my watch were not related by any relationship worth exploring but certainly (and intuitively) they are not related by a simple shift. What can be said however is that the rate at which the backtest ran was 1 year of data / 5 minutes of my time = 73 days/min

Im not saying this information is practical on any bottom-line level but its kinda cool I think. Moreover, I can run some backtests, note the rate, and perhaps modify my code/algorithms to improve it. When it comes to computation heavy processes.. strategy optimization being one... an efficient algorithm can make a significant difference over an inefficient one. In fact, when comparing performance improvement by improving an algorithm vs adding computing power, a more efficient algorithm will always prevail.

Having implemented this (thanks to the code provided by brewmanz) I found my EA tests at about 18 days/min in visual mode, and about 24 day/min without visual mode... not sure how that actually compares but it seems kinda slow to me.. :-/

 

@supertrade: Yeah, I get it now. :)

You're looking for how long the Test ran. Sorry I mis-understood the original post. I'm kinda looking into that same issue right now. Dumping all my functions into a library file came back to bite me in terms of speed in completing a back-test. While researching the problem yesterday, I found out about Recursive Functions and Memory Leak here. I also learned about limiting custom indicator bars and changing the priority under windows task manager can help.

I'm not sure what Recursive functions mean. My best guess after looking it up is -function called within another function-. Looks like setting the stack-size might help also. Can someone who understands this clarify?

The method provided by brewmanz helps us measure if changing the codes or whatever helps speed up the EA. And I'll sure be using it from now on.

 
Cool. Thanks for that link, Im definitely going to investigate.. seems like MT4 does not go to great lengths in the way of efficiency.
Reason: