MT5 and speed in action - page 70

[fxsaber]

Please add the required functionality.

Forum on trading, automated trading systems and trading strategy testing

New version of MetaTrader 5 build 2650: Background Loading of Charts and Improvements in the MQL5 Code Profiler

fxsaber, 2020.11.04 16:50

Unfortunately, they did not add features to minimise windows of Charts, Terminal, Market Watch, etc. Earlier evidence was given that minimising these windows reduces the CPU load.

And stop displaying data in Market Watch window and others, when Terminal window is not visible. For example, when the current application (e.g. browser) is active and maximized.

The bearded need is to determine which chart is currently selected. People are forced to use crusty WinAPI solutions.

[Renat Fatkhullin]

Yes, MetaTrader VPS has orders of magnitude less latency(emissions of latency) and many times more all resources compared to regular VPS from hosting providers.

It's been explained many times why.

Guaranteed zero latency in execution threads cannot exist within current (all) processor architectures. Tales of" real-time systemoperating systems" remain myths, you don't need to mention them.

[Renat Fatkhullin]

fxsaber:

I see what's going on with the single ejections, thanks for the detailed explanations. At this point, though, we are not discussing SymbolInfoTick, but lags of a different nature, which rush on almost every tick.

This is only about your single emission measurements - they are no longer accepted or considered. Your entire analysis was built solely on emissions.

Other issues can only be considered if the scenario is clearly and fully described in one comment, without "actually meant other comments" and without rolling into single command metering.

[fxsaber]

Renat Fatkhullin:

Other issues can only be considered if the scenario is clearly and fully described in a single comment, without "actually meant other comments" and without rolling into single command metering.

Here at the links are the details, including comments in the source code.

Forum on trading, automated trading systems and trading strategy testing

MT5 and Speed in Action

fxsaber, 2020.11.05 07:42

Who is using VPS from MQ, please share the results of the following programs there.

1. Expert Advisor that catches OnTick/OnBook lags.
2. Expert Advis or that catches ticks with old time.
3. Ascript that measures average execution time of Sleep(1).

[Maxim Dmitrievsky]

There is a platform called deltix (not to advertise it). When I was talking to the developers (I wanted to connect it for arbitrage some time ago), they explained the same thing about single delays, that it is normal and you need to look at the average

This is by the way, without any stones in anyone's breach

[fxsaber]

Since single outliers inevitably occur, it is logical to have regular functions that return an array of the entire Market Watch and an array of all current positions/orders. Similar to MarketBookGet.

Right now cycles have to be run. This is VERY expensive.

Forum on trading, automated trading systems and testing of trading strategies

MT5 and Speed in Action

fxsaber, 2020.10.07 12:41

Practical necessity makes you write it that way.

// Возвращает время Обзора рынка в миллисекундах.
long TimeCurrentMsc()
{
  long Res = 0;
  
  MqlTick Tick;
  
  for (int i = SymbolsTotal(true); i >= 0; i--) 
  {
    const string Symb = SymbolName(i, true);
    
    if (SymbolInfoTick(Symb, Tick) && (Tick.time_msc > Res))
      Res = Tick.time_msc;
  }

  return(Res);
}

I've never tried to put the EA into MQL5, and I've never tried to add it into MQL5.

[Roman]

Slava:

There will be no acceleration. Present your calculations, at least in rough figures, proving multiple acceleration.

A race for resources? Uncontrolled creation of new streams? Conflicts over nothing?

Do you want unexplained slowdowns?

In the event-based model, all events have always gone in formation, one at a time. Chewed up - chewed up.

No acceleration of event processing, in an asynchronous architecture? Are you serious?
Accelerated processing of user programs, specifically their handlers. That's what I'm talking about.
I understand that you are trying to minimize the use of threads. But one of the alternatives is to run each handler in a separate thread.
No uncontrolled creation of threads. In a user program there are only a few handlers, each of them should be started in its own thread at the start of the program.
And you synchronize the events between the handlers with mutexes or whatever.

But if threads are a pain for you, as you mentioned, there is an event model that allows you to work in a single thread.Event Handling, in an event loop with a task run.
The event loop, although it runs sequentially, but the tasks in that loop are handled in parallel!
This is what I mean, all the handlers in the program run in this event loop, then all the events will be asynchronous and arrive simultaneously in real time.
That is, the same events in OnTrade andOnBookwill be matched.
Please ask how an event loop works in other languages.
If the event loop already exists in the terminal, just apply it to handlers in programs. That's all.

[fxsaber]

Roman:
Each handler should be run in a separate thread.

The problem is not solved in any way. MQL programs will become much more complicated if different threads read\write access to internal variables, for example.

[Roman]

fxsaber:

The problem is not solved in any way. MQL-programs will become more complicated by an order of magnitude, if read\write access to internal variables from different threads, for example.

The MQL-programs will not get more complicated, it's just a synchronization headache for developers. Which they are not willing to solve, of course.
Or a deadlocked initial architecture of the project not designed for this model.
And no one will rewrite the project for a new model, of course.
The event loopmodel is better suited for handlers. This is what I was trying to say.
And this model has most likely already existed in the terminal for some time, it just hasn't been applied to the handlers.

[fxsaber]

Roman:

MQL programs will not get any more complicated...

I suggest this is the end of the theorising, which will never intersect with practice here.