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

 
Vasiliy Sokolov:
s.s. Specifically on the subject of storing strings in MT objects, there's one weird glitch. If you start compressing the data and use unprinted characters in the object name, in some cases you won't be able to access that object. The glitch is probably still there because it's very specific and not many people know about it, but you might stumble upon it nonetheless.

I see. Only practice will help to figure it out definitively.

 
Реter Konow:

Dear opponents.

Here is the script code which:

  1. Measures the time of transferring a string to a Char array, for passing the string to another program via a resource and the time of retrieving a string from a Char array for subsequent splitting and retrieval of information.
  2. Measures the time to write the string to the MT object description and the time to retrieve the string from the MT object description, for subsequent splitting and retrieval of information.

Result:


Peter, you're testing the wrong thing in the wrong place. What you're testing should have about the same speed in terms of string logic.

You completely misunderstood my message.

My message was that you should stop using strings to pass double,long,time,int etc. And if you need to pass text, then translate a text string to uchar array. And all mixed data of different types via union data structures or arrays of these structures, converted to uint arrays via union, should be passed through resources, and on the receiving side these uint arrays should be converted back via union to the original structures. Believe me, Peter, thongs are very slow, you should always avoid them where possible. String is needed only for text and print output.

And in your example you've got the notion of performance measurement completely wrong.

Especially via the OBJPROP_TEXT property you can pass a string with a maximum size of 63 bytes. This is nothing.

Although your example makes no sense at all, but I modified it to something more correct purely for demonstration purpose and this is what I've got when copying 1000 different strings with size 63 bytes:

The script code is attached. It works on both MT4 and MT5

MT4:

2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через свойство объекта:      2309 правильность копирования - true
2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через uchar массив:          1882 правильность копирования - true

MT5:

2018.12.19 00:32:30.857 TestStringVsCharArray (NZDUSD,M1)       время через свойство объекта:      32811 правильность копирования - true
2018.12.19 00:33:00.678 TestStringVsCharArray (NZDUSD,M1)       время через uchar массив:          364   правильность копирования - true

It seems that MT5 is asynchronous, so your method is 100 times slower and not suitable for MT5 at all. You should more and more focus on MT5

And what is it?

StringToCharArray(qwerty,Arr,0,WHOLE_ARRAY);

You should at least read the Help

 
Реter Konow:

Dear opponents.

Here is the script code which:

  1. Measures the time of transferring a string to a Char array, for passing the string to another program via a resource and the time of retrieving a string from a Char array for subsequent splitting and retrieval of information.
  2. Measures the time to write the string to the MT object description and the time to retrieve the string from the MT object description, for subsequent splitting and retrieval of information.

Result:


Read carefully and conclude: https://docs.mql4.com/ru/basis/types/stringconst
To help with the conclusions:
1. 2 bytes are allocated for each character in the string, Unicode encoding. Not full use of string capacity.
2. When using CharArrayToString function (and reverse), conversion according to encoding of characters in uchar array is performed, which also eats CPU time. Use ShortArrayToString(and vice versa).
Try it, but note that in Unicode string must end with zero.
 
Aliaksandr Hryshyn:
Read carefully and conclude: https://docs.mql4.com/ru/basis/types/stringconst
I will help with the conclusions:
1. 2 bytes are allocated for each character in the string, Unicode encoding. Not full use of string capacity.
2. When using CharArrayToString function (and vice versa) , conversion according to encoding of characters in uchar array is performed, which also eats CPU time. Use ShortArrayToString(and vice versa).
Try it, but note that string must end with null in Unicode.

don't agree. We need uchar array for string as an intermediate. And there is no conversion, just copying bytes.

 
Nikolai Semko:

I don't agree. We need a uchar array for the string as an intermediate. And there is no conversion, just copying of bytes.

Try to pass Cyrillic characters. And compare the character codes in the uchar array and in the string, the string is passed as a ushort array.
 
Aliaksandr Hryshyn:
Try to use Cyrillic characters. And compare character codes in uchar array and in string, string is like ushort array.

I know what unicode is. But in our case we need uchar array only to get uint array through union to pass it further through the resource and when getting back chain of string recovery. There will be no losses. And in this case we do not need to extract characters from uchar array.

Encoding can be changed and is non-unicode by default.

 
Nikolai Semko:

Peter, you're testing the wrong thing in the wrong place. What you're testing should have about the same speed in terms of string logic.

Nikolai, with all due respect, that's empty words for nothing. I have measured and attached a script. "The right way, the wrong way...", "should have approximately the same speed in terms of string logic"... Just words.

Nikolai Semko:

...

You completely misunderstood my message.

My message was that you should stop using strings to pass double, long,time, int etc. And if you need to pass text, then convert a text string to uchar array. And all mixed data of different types via union data structures or arrays of these structures, converted to uint arrays via union, should be passed through resources, and on the receiving side these uint arrays should be converted back via union to the original structures. Believe me, Peter, thongs are very slow, you should always avoid them where possible. String is needed only for text and print output.

That's exactly your message I understood perfectly. AND IT'S WRONG.

Why? - Because you would have to complicate the system of working with control parameters a LOT. The architecture of storing, passing and managing parameters will become TUCH more complicated and confusing, which will lead to a lot of problems and an overall slowdown.

You don't understand the internal architecture. You don't know how programs interact, manage parameter values according to their type and properties. What you propose would make things a lot more complicated and confusing. And it won't solve the communication problem. It will still remain crutchy.

Nikolai Semko:

...

All the more you can pass a string with a maximum size of 63 bytes through the OBJPROP_TEXT property. That's nothing.

Although your example makes no sense at all, I reworked it to something more correct purely for demonstration purposes, and here's what I got when copying 1000 different strings with size 63 bytes:

...

You can pass a string of 64 characters through the description of one MT-object. That's enough. I need - 20-30 lines to transfer data of big tables. Without large tables, I need 2-3 lines at most.

I am interested in MT4 at the moment.

MT5 is developing all the time. Developers can just add common memory of MT-programs (so they don't have to fuss with resources) and the question will be removed.

 

Nikolai Semko:

...

My message was that we should stop using strings to pass double,long,time,int etc.

...

How do you transfer double,long,time,int etc... ???

All the same we need to convert it to string and then to char to write it into the resource.

Or do you suggest using lparam,dparam ?

That is, overload the event queue...

 
Реter Konow:


Bummer. I'm off the subject.
Kindergarten, second quarter.
You bore me, Peter, with your illiteracy and ignorance and your overweening sense of self-importance and entitlement.
 
Nikolai Semko:


Also, in your measurements, you forgot to add the time to save and read the resource...

So, even if you write 1000 lines (which is really better to pass through the resource), you don't gain in speed, due to the cost of saving and retrieving from the resource.