Libraries: TesterBenchmark - page 3

New comment
 
Andrey Khatimlianskii:

Vasily, are you seriously talking about commensurability of OrderSend execution speed in tester and in real?

Online it is the slowest, because it sends information to the server and waits for a response, while in the tester (if you don't include the delay, but it was out of the question), sending and waiting happen instantly.

The task of this library is just to measure the speed of the tester (in terms of trading functions).

Yes, I didn't think about it. My mistake. Specifically OrderSend works much faster in the tester. But I still say that the lion's share of testing time is eaten up by system functions. And in MT5 it is eaten very well, because there, unlike MT4, there is a full simulation of the trading environment. That's why even if the pipelining is accelerated by 16%, it will be 16% of 5% of the total time taken by this very pipelining. That is, any ideas of code optimisation in MT5 are very noble, but pointless, because at best we will improve the index by these 5%.

 
Vasiliy Sokolov:

Yeah, I wasn't thinking. My mistake. OrderSend works much faster in the tester. But I still say that the lion's share of testing time is eaten up by system functions. And in MT5 it is eaten very well, because there, unlike MT4, there is a full simulation of the trading environment. That's why even if the pipelining is accelerated by 16%, it will be 16% of 5% of the total time taken by this very pipelining. That is, any ideas of code optimisation in MT5 are very noble but pointless, because at best we will improve the index by these 5%.

I disagree with the last statement.

Thanks to fxsaber's research, MT5 has already accelerated the work with the history of trades by orders of magnitude.

 
Andrey Khatimlianskii:

I disagree with the last statement.

Thanks to fxsaber's research, MT5 is already orders of magnitude faster in working with the history of trades.

I am not arguing. Fxsaber contributes a lot to the development of the language and the community in general. He does the right things. There are a lot of errors in MT5 and it is great that someone finds them. But one should not confuse gross errors in MT5 work, as a result of which the work speed decreases by orders of magnitude, and catching fleas in the SB code. Somewhere it is certainly possible and even necessary to speed up the lib. But if there are no gross errors in it, there will be no acceleration by orders of magnitude.

 
Vasiliy Sokolov:

I'm not arguing. Fxsaber contributes a lot to the language and the community as a whole. He does the right things. There are a lot of errors in MT5 and it is great that someone finds them. But we should not confuse gross errors in MT5 work, as a result of which the work speed decreases by orders of magnitude, and catching fleas in the SB code. Somewhere it is certainly possible and even necessary to speed up the lib. But if there are no gross errors in it, there will be no acceleration by orders of magnitude there.

I haven't even thought about SB.

I think it just came to hand for comparison.

 
Andrey Khatimlianskii:

I disagree with the last statement.

Thanks to fxsaber's research, MT5 has already accelerated the work with the history of trades by orders of magnitude.

By the way, by the way, thehistory of trades screwed up back in 2013. I remember then I noticed that the following code does not work linearly:

int total = HistoryDealsTotal();
for(int i = 0; i < total; i++)
{
   ulong ticket = HistoryDealTicket(i);
   HistoryDealSelect(ticket);
}

I.e. the more i is, the slower HistoryDealSelect works. The slowdown was exponential. So I had to draw a graph of this slowdown in Excel and communicate with Service Desk. So, yes, there were and will be bugs.

 

Now I have tweaked the code a bit by changing OrderSend to OrderSendAsynch. The results are expectedly different:

85% of time is taken by HistorySelect. I.e. we are back to system calls, but a bit different.

 
The library was written for this purpose
When writing different code versions, it may be necessary to measure their influence on the overall performance of the Expert Advisor in the tester. This allows you not only to understand how optimal the written code is in comparison to another, but also provides prerequisites for future rapid optimisation of the Expert Advisor. This approach allows us to identify the "bottle neck" in the EA's performance.

And this approach worked not only with MT4Orders.mqh, but also with Trade.mqh - it became noticeably faster after SD. Also the results of using the library allowed us to noticeably speed up some other things(in particular).

Sound rational solutions, etc.

Fact - time to Optimisation depends very much on how the code is written. The library wanted to conveniently draw not only my own, but also others' attention to this.

As an example (may the Author forgive me), there are many EAs in kodobase which, in terms of performance, do not shine in Optimiser at least because of the trading library used. In fact, this is even a certain scourge of kodobase (and, I'm sure, Market), when a smart and strong OOP advisor negates all the speed capabilities of the MT5 tester.

Almost nothing seems to be written for the tester. And this is a huge component of working with TS.

 
fxsaber:

... when a smart and strong OOP advisor nullifies all the speed capabilities of the MT5 tester.

Take another look at the profiling of your example. Everything is hindered by the infernally slow HistorySelect(0, TimeCurrent). In OOP you can bypass the call of HistorySelect, which significantly reduces the execution time of the programme compared to the call of pure MQL5 functions. The statement that OOP nullifies all the speed capabilities of MT5 is incorrect. In some cases, thanks to it, you can speed up on the contrary, as in the case of HistorySelect.

 
Vasiliy Sokolov:

Take another look at the profiling of your example. Everything is hindered by the infernally slow HistorySelect(0, TimeCurrent). In OOP it is possible to bypass the call of HistorySelect, which significantly reduces the execution time of the programme compared to the call of pure MQL5 functions. The statement that OOP nullifies all the speed capabilities of MT5 is incorrect. In some cases, thanks to it, you can speed up on the contrary, as in the case of HistorySelect.

For some reason you do not see that HistorySelect is called only when there are no open positions. Moreover, a new position is opened immediately after that. That is, history is called very rarely. There is a fact (check at least by the time in the logs) that the time in the Tester differs depending on the implementation.


I write everything through OOP and never even hinted at its possible slowness. The vast majority of authors especially keen on OOP create sometimes VERY convenient and beautiful designs. However, they do not pay attention to the performance of their solutions. And this is very important for a tester. Everyone wants to optimise their EA for many hours faster (or cheaper in the Cloud). It often happens that some long-written and automatically pluggable OOP module contains a bottle neck. But nobody notices it, of course.


You can write your own Expert Advisor that shows the performance of the used trading API. For example, remove history access and lot calculation from the original one.

 
fxsaber:

You can write your own Expert Advisor that shows the performance of the used trading API. For example, from the original one throw out the history access and lot calculation.

In CStrategy trading operations are performed through CTrade directly. That is, CStrategy has no trading logic of its own at all. In the test Expert Advisor I did not see any other trading logic than opening/closing a position after N seconds. CStrategy also does not store historical positions, so this example is unfortunately not realisable in CStrategy.

fxsaber:

The vast majority of Authors especially passionate about OOP create sometimes VERY convenient and beautiful constructions.

The vast majority of authors who are passionate about OOP do not exist in principle, unfortunately. There may be only 5-10 OOP authors for the whole resource, including SB authors from MetaQuotes. We are few and we are in seals:)

fxsaber:

I write everything through OOP and never even hinted at its possible slowness. The overwhelming majority of authors especially keen on OOP create sometimes VERY convenient and beautiful designs. However, they do not pay attention to the performance of their solutions. And this is very important for a tester. Everyone wants to optimise their EA for many hours faster (or cheaper in the Cloud). It often happens that some long-written and automatically pluggable OOP module contains a bottle neck. But of course nobody notices it.

The fact that OOP code executes slower than procedural code does not tell me anything. Let's get to the point: which CTrade methods are the bottle neck? Why? What does the profiling of these methods tell you? How do you identify slow code sections in the tester?

1234
New comment