MQL5 bug when working with iClose/iOpen timeseries access, etc. - page 3

[transcendreamer]

For example, given that the developers are clearly professionals, experts in architecture and speed optimisation, it should not be difficult for them to write such a function in the correct way and include it in the standard library, for which the grateful users will be extremely grateful.

[Unicornis]

Renat Fatkhullin:

Think about where the data (the more so it is guaranteed) will be available, when your indicators tremendously slow receiving/laying ticks, spending hundreds of milliseconds or even seconds for one tick. As a result, no CPU is sufficient in time to process ticks, which translates into an accumulating deficit and a corresponding stall in the chart history.

When you ask for "guaranteed give", it is most likely a request of "don't want to know anything, want to keep writing as I want, don't want to think about performance and locks, just give"?

When you have millions of bars available to you, think about the performance of your and other people's indicators. A poorly written and expensive indicator can easily stall chart updates of its symbol.

Start by measuring the OnCalculate response time in microseconds. Then divide 1 second by the average tick response time to get the maximum tick throughput of the indicator in ticks per second.

This is immediately sobering.

Let's leave only one tick (a new bar) for the new type of data processing by the indicator in the proposed version. Those who like multiple recalculations of zero bars and the grail in the zero bar should enjoy the existing version. Add a new function to OnInit - iOnCalculate - a handle to one of the TF functions / OnCalculate in the indicator, like iCustom, but it is a little closer, the indicator buffers on OnCalculate should be bound to the handle iOnCalculate. In the indicator functions like OnCalculate, send only a new tick bar. For the terminal, nothing will change, the basic logic of OnCalculate will be the same, the main body of the indicator will be added, for example OnMain. (Now everything is done by the indicator(s), attached to the main indicator as a resource and called from it on a new bar).

[Renat Fatkhullin]

transcendreamer:

You don't always need super speed, usability is also very important, nowadays writing multicurrency indicators is like "setting the sun by hand", even in MT4 it was easier, because you could always get it through i-functions, even if slowly, but you could get it, but in MT5 you can either get it or not, and you still need to make a special code yourself.

Let's skip the theories.

Just submit an example to be reproduced and we'll see what horror is around your case. So far it looks like a total disregard for performance, hiding killer retard indicators and trying to cast a shadow.

[transcendreamer]

Renat Fatkhullin:

Let's skip the theories.

Just provide an example to reproduce and we'll see what horror surrounds your case. So far it looks like a total disregard for performance, hiding the killer retard indicators and trying to put a shadow over it.

The example in the attachment, it is not the finished code, it is incomplete in some places, but it is possible to run it, I am also attaching a template for convenience,

i will tell you right away, i am not a programmer, for sure the code is not optimal, i am a humanitarian economist, i really suffered in MT5, i suffered less in MT4,

I really want a simple and reliable function that would build a synchronized array as described above https://www.mql5.com/ru/forum/289897/page2#comment_9363454.

I'm not complaining, I'm not asking to write my indicator, I just want (not only me by the way) a nice standard function.

EDIT: corrected the attachments

[Stanislav Dray]

Renat Fatkhullin:

Do as I advised, please.

Otherwise you need full materials for 100% playback.

Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I described the situation as best I could.

I'm not the only one with this problem. This problem occurred after your 30th update, but still you insinuate that I am an idiot and some slow-moving indicators are to blame.

Weren't they slow for a year before that?

Here is an example of code which hangs after 25 minutes on M30:

//+------------------------------------------------------------------+
//|                                                      Feezzzz.mq5 |
//|                                   Copyright 2018, Dray Stanislav |
//|                               https://www.mql5.com/ru/users/fan9 |
//+------------------------------------------------------------------+
#property copyright "Copyright 2018, Dray Stanislav"
#property link      "https://www.mql5.com/ru/users/fan9"
#property version   "1.00"
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
//---
   
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
//---
    datetime CM1_T[1];
    if(CopyTime(_Symbol,PERIOD_M1,0,1,CM1_T)==-1){
      Comment("\n\n CopyTime return -1");
      return;
    }
    Comment("\n\n CopyTime : "+TimeToString(CM1_T[0],TIME_DATE | TIME_SECONDS));   
  }
//+------------------------------------------------------------------+
//| Trade function                                                   |
//+------------------------------------------------------------------+
void OnTrade()
  {
//---
   
  }
//+------------------------------------------------------------------+

And here's the result:

[Renat Fatkhullin]

transcendreamer:

The example in the attachment, it is not yet complete code, in some places not written, but you can run it, I am also attaching a template for convenience,

i can promise that i am not a programmer, for sure the code is not optimal, i'm a humanitarian economist, i really suffer in MT5, i suffered less in MT4,

I really want a simple and reliable function that would build a synchronized array as described above https://www.mql5.com/ru/forum/289897/page2#comment_9363454.

I'm not complaining, I'm not asking for trouble,

I'm not complaining, and I'm not asking to write my indicator for me, I just want (not only me by the way) a nice standard function.

EDIT: corrected the attachments

Thank you, we'll be checking now.

[Renat Fatkhullin]

Stanislav Dray:

Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I have described the situation as best I could.

What I wrote earlier in this thread does not qualify as a bug report in any way.

All went on the pattern of complaints without any technical details. It was only after my enquiries that the details started to emerge.

[Vladimir Karputov]

Stanislav Dray:

Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I've described the situation as best I could.

The problem is not only me, the problem appeared after your 30th update, but still you insinuate that I am a fool and blame some retarded indicators.

Weren't they slow for a year before that?

Here is an example of code which hangs after 25 minutes on M30:

And here's the result:

Uploaded

2018.11.14 17:33:32.570 Experts expert Feezzzz (USDCHF,M30) loaded successfully

It's now 18.10 Everything is working.

[Renat Fatkhullin]

transcendreamer:

The example is attached, it's not yet complete code, it's underwritten in some places, but it can be run, I'm also attaching a template for convenience,

I'll show you the code and the work at once:

1. CopyXXX functions in indicators do not wait for full synchronous data downloading, but give what is available. Otherwise indicators would have completely frozen everything.
   
   
2. Apparently there is a problem with the follow-up, if all the data was not synchronized the first time.
   It's necessary to change to a gentle mode "I will carefully wait for successful downloading". For example, OnCalculate is not called.
   
   
3. The bad thing is that a global initialization with the maximum load is placed in OnInit where the indicator counts and waits for a very long time.
   In this case the update of charts of this symbol is blocked and many other participants have to wait and not receive fresh data. The indicator should not take resources for a long time. It's better to stretch the long initialization step by step/symbol initialization in OnCalculate, counting step by step.
   
   
4. I've had this indicator pump out about 800 MB of historical data over the network for synchronization
   
   
5. The indicator has 512 drawing lines that are explicitly allocated memory for. This is extremely expensive. Only 100 lines are used.
   
   
6. The code is poorly readable

[Renat Fatkhullin]

Stanislav Dray:

Your attitude to bug reports is strange. It's not like I'm paid to prove anything. I've described the situation as best I could.

The problem is not only me, the problem appeared after your 30th update, but still you insinuate that I am a fool and blame some retarded indicators.

Weren't they slow for a year before that?

Here is an example of code which hangs after 25 minutes on M30:

And here's the result:

I put the code to work. So far so good.

A file without a body, by the way.