My approach. The core is the engine. - page 125

New comment
 
Реter Konow:

So they are redrawn exactly as you said.

And the load on the processor comes from the animation:

There is a constant re-initialization of the values in the pixel array. Every 16 milliseconds. This loads the processor up to 40%.

I was trying to figure out what exactly the load is. I thought it was saving a resource or reading it. It turned out that it was the reinitialization of the array in the drawing loop.


It also turned out that a constant call of ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1); (every 16 ms) also loads the processor. By about 10%.

I use this call to tell another EA to read the resource with animation data.

In total, it gets +~50% CPU load during animation.

Sorry, didn't notice that it's no longer about the list of open trades. Gone, I think, are the 2-3 pages of the thread.
 
Vladimir:
Sorry, didn't notice that it's no longer about the list of open trades. Gone, I think, 2-3 pages of the thread.

No, it's fine. I just brought up the CPU load because I'm going to redo the communication between the EA and the engine, which means that the open trades table will also take data differently.

 
Why do you need 64 frames per second (16ms), 32 frames per second is enough for the eye.
 
Nikolai Semko:
Why make the periris 64 frames per second (16 ms), for the eye is enough 32 frames per second.

Good question. In fact, the timer doesn't work smoothly. There are skips. 16,32,16,16...

If you use 32, the skips are 64 ms. And this is noticeable. Besides, various other things also burden and slow down drawing. For instance, the OnChartEvent() event queue.

I think it affects the quality of animation. I tried to use 25 ms. Then 16, and came to the conclusion that 16 better conveys a smooth motion.

Later skolnuyu engine with animation 16 ms and 32 ms and you'll see for yourself. Although, maybe it will be ok....

 
Реter Konow:

Good question. In fact, the timer doesn't work smoothly. There are skips. 16,32,16,16...

If you use 32, the skips are 64 ms. And this is noticeable. Besides, various other things also burden and slow down drawing. For instance, the OnChartEvent() event queue.

I think it affects the quality of animation. I tried to use 25 ms. Then 16, and came to the conclusion that 16 better conveys a smooth motion.

Later skolnuyu engine with animation 16 ms and 32 ms and you'll see for yourself. Although, maybe it will be ok....

It's just that it's not really 16ms, but 1000/64=15.625ms. That is why it is better to set 30 ms instead of 32 ms, then there will be fewer skips. i.e. if you put a pause between frames of 33 ms, then the real pause will be 15.625×3=46.875 ms.
And you have to remember that MT has its own internal chart update handler, so ChartRedraw will work asynchronously and there is no guarantee that MT will handle them all.

 
Nikolai Semko:
It's just that it's not really 16ms, but 1000/64=15.625ms. That is why it is better to set 30 ms instead of 32 ms, then there will be fewer skips. i.e. if you put a pause between frames of 33 ms, then the real pause will be 15.625×3=46.875 ms.
And we have to remember that MT has its own internal chart update handler, so ChartRedraw will work asynchronously and there is no guarantee that MT will handle them all.

Why? Simple, interesting.

 
Алексей Тарабанов:

Why? Simple, I wonder.

I just came to these conclusions after a lot of experimentation and scientific trial and error. If anyone has any experiments that can disprove my assertions, I would be very grateful.
 
Nikolai Semko:
It's just that it's not really 16ms, but 1000/64=15.625ms. That is why it is better to set 30 ms instead of 32 ms, then there will be fewer skips. i.e. if you put a pause between frames of 33 ms, then the real pause will be 15.625×3=46.875 ms.
And you have to remember that MT has its own internal chart update handler, so ChartRedraw will work asynchronously and there's no guarantee that MT will handle them all.

OK, I'll take that into account.

Reducing the timer frequency will certainly reduce the load on the processor. If it doesn't degrade the quality of the animation, great. The CPU load may be reduced by up to 30 percent, but it still will be.

You'll have to put up with it.

Admittedly, if the drawing distributed between different threads, (eg part of the animation draws the Expert Advisor, and part of the engine), then the load would be almost removed. We have to think...

 

Alas, my assumption was not confirmed.

Now I have done an experiment - I put one EA on two charts. The Expert Advisor loads the processor by 50%.

I have found out that even when working with different charts, CPU load is summing up and the total load of CPU on MT's side is over 90%.

So, even splitting the charting between different Expert Advisors will not help. The load is adding up!

 
Реter Konow:

Alas, my assumption was not confirmed.

Now I've done an experiment - I put one EA on two charts. The Expert Advisor loads the processor by 50%.

I have found out that even when working with different charts, CPU load is summing up and the total load of CPU on MT's side is over 90%.

So, even splitting the charting between different Expert Advisors will not help. The load is adding up!

If it is MT4, then yes.
As I understand MT5 fully supports multi-core and multi-threading in contrast to MT4.
1...118119120121122123124125126127128129130131132...184
New comment
Reason: