Errors, bugs, questions - page 2749

[Alexey Navoykov]

Roman:

On the previous page fxsaber gave measurements.
I explained why this is the case.
Always allocate memory, statically or dynamically.

What kind of measurements? If you mean big table, then only left part is visible on the screen, the rest is cut off, so I don't know what's there.

But judging by the code, if this macro is compared

GetCurrentTick2(Tick, !i)

I've got only one function call per 100 iterations. And the first macro has a call at each iteration. So it doesn't make sense.

[Roman]

Alexey Navoykov:

If you mean the big table, only the left part is visible on the screen, the rest is cut off, so I don't know what's there.

But judging by the code, if this macro is compared

And in the first macro, there is only one function call per 100 iterations. So, this is nonsense.

The compiler is not omnipotent, sometimes you have to participate and help it with the right code ))

[Ilyas]

Sergey Dzyublik:
Bug in ME debugger(build 2370) - StepInto (F11) and manually set breakpoints does not work.
The problem is that if the StepOver (F10) action is applied to a function call at least once, there is no way to debug this function later.

Replay steps:
1) Run code in debug mode;
2) After a breakpoint is triggered, execute StepOver (F10) twice;

Everything - now there is no way to "get" intoIncrement function, all manually set breakpoints are not triggered, and instead of StepInto operation (F11), StepOver (F10) is actually executed.

Thanks for the post.

Corrected by

[Alexey Navoykov]

Roman:

The compiler is not omnipotent, sometimes you have to get involved ))

What do you mean? You assured me that your construct is faster, but it's not. It's just 100 times less likely to be called in that code.

[Sergey Dzyublik]

Alexey Navoykov:

In the first macro, there is only one function call per 100 iterations. So this is nonsense.

The test, if not to pick on precision, which we don't need here, is plus or minus normal.
Compared to: calling 100 times SymbolInfoTick VS calling 1 time SymbolInfoTick and returning 99 times "manual" cache.
Shows how it's unprofitable to use the standard SymbolInfoTick function for the current symbol when the function will be called more than once on a single pass.
As a possible solution to the problem, the developers suggest introducing a predefined variable:

const MqlTick _Tick; // Текущий _Symbol-тик.

It's just thatfxsaber has scattered everything over the posts without explaining anything at all, it's a hell of a thing to do.

[Igor Makanu]

Alexey Navoykov:

In the first macro, there is only one function call per 100 iterations. So this is nonsense.

His example is a specific use of bid/ask data in different parts of MQL-program, the more often you access SymbolInfoTick(), the lower is the testing performance

I've found some performance issues with TimeCurrent(), I've tried it in different ways, then discarded it,

I seldom use global variable visibility, but for everything to "fly" in the tester, I write it this way:

MqlTick Tick = {0};
#define  Ask Tick.ask
#define  Bid Tick.bid
#define  TimeCurrent_ Tick.time
//+------------------------------------------------------------------+
void OnTick()
{
   SymbolInfoTick(_Symbol,Tick);
  ....
}

[Roman]

Alexey Navoykov:
What do you mean? You assured me that your design is faster, and it's not faster, it's just 100 times less likely to be called in that code.

This is not my design, and as I understood from that example, the macros were called one by one for the test.
And the pass report is shown together, even though it's cropped, you can see the execution time.

[Alexey Navoykov]

Sergey Dzyublik:

The test, if you don't care about accuracy, which you don't need, is plus or minus normal.
Compared to calling SymbolInfoTick 100 times VS calling SymbolInfoTick once and returning 99 times "manual" cache.

Yes, I understand about the cache. It's just Roman here was rubbing something about memory allocation... Looks like you were right about the troll )

[Roman]

Alexey Navoykov:

I know about the cache. It's just that Roman here was rubbing something about memory allocation... Looks like you were right about the troll )

Where do you think the cache is allocated? You dweebs.

[fxsaber]

Sergey Dzyublik:

The test, if you don't care about accuracy, which you don't need, is plus or minus normal.
Comparison: calling 100 times SymbolInfoTick VS calling 1 time SymbolInfoTick and returning 99 times "manual" cache.
Shows how it's unprofitable to use the standard SymbolInfoTick function for the current symbol when the function will be called more than once on a single pass.
As a possible solution to the problem, developers are encouraged to introduce a predefined variable:

You get my point 100%.

The reason is thatfxsaber had spread everything in his posts without explaining it and it's hard to understand.

I'm sorry, I don't formulate it well.