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

[Maxim Kuznetsov]

Реter Konow:
The engine and the advisor work in a flow of communication. Each cell in the table is a number of simovalves. On top of that, there are a lot of other elements that pass their values, states, and so on. You need to exchange rows quickly and not overload OnChartEvent() event queue.

Take SQL and don't rack your brains :-)

[Реter Konow]

Nikolai Semko:
You mean you have no idea how to do it with resources and union?

I assure you this is the quickest solution.

Come on, move your brain.

After you, Nikolai.

You offered the option with union, but you didn't show me an example. Then you switched toCharArrayToString andStringToCharArray. Now you are speaking about a union again.

So, is it the best solution to go from String to Char and then back, with subsequent splitting of strings (strings contain an assembly of parameter numbers and their values)?

[Реter Konow]

For the sake of interest, I'll try the union variant. And withCharArrayToString andStringToCharArray. Although my gut tells me that it's unlikely to be faster than communication via description of МТ objects. But I may be wrong. Let's see...

[Nikolai Semko]

Реter Konow:

After you, Nikolai.

I don't want to rip you off by doing your job. It's important to me that you do it yourself. Otherwise you won't understand.

Piotr, tell me, do you also use thongs to pass double, long and int?

[Реter Konow]

Nikolai Semko:
Tell me, Peter, do you also use strings to pass double, long and int?

The core of the parameters is a single array. And it is of type string. For one reason - it is a universal type. It is very convenient. You may write any value and then convert it to the required type.

Otherwise, it would be necessary to create many cores of parameters. Each one for its own type of value. As a result, we would have a mess of parameters' attributes, their indexing, writing location and many other things.

[Реter Konow]

Nikolai Semko:

I don't want to rip you off by doing your job. It's important to me that you do it yourself. Otherwise, you wouldn't understand.

Let's not troll. Mentoring isn't appropriate. I understand more about this job.

Nikolai, I told you I'll try your version.) So I will.

[Maxim Kuznetsov]

Maxim Kuznetsov:

take SQL and don't worry about it :-)

As if to follow up on the "don't mess with your head" thing :-)

I'm kind and not at all evil today...

Peter, about "visual programming" (not just GUI), for development, so you don't have to build an array-on-a-array,
have a look at Oracle, for example. One of the clear leaders

Visual editor for free (together with virtual machine) it's here ; https://apex.oracle.com/en/

All you need to get started is a book from "The Beginnings of SQL for Dummies" and a couple of days of free time.

[Nikolai Semko]

Реter Konow:

Let's not troll. The mentoring tone is inappropriate. I understand more about this job.

I'm not trying to dissuade you of that.
I didn't have any such tone. It's just that I've posted code for you several times now that was much faster than yours, in the hope that you would learn it and apply faster methods, but you've never taken advantage of it.

Why should I do the thankless job.

[Nikolai Semko]

Реter Konow:

The core of the parameters is a single array. And it is of type string. For one reason - it is a universal type. It is very convenient. You may write any value and then convert it to the required type.

Otherwise, it would be necessary to create many cores of parameters. Each one for its own type of value. As a result, there would be a mess with parameters' ownership, indexing, writing location and many other things.

Versatility is often synonymous with slowness, and even more so with strings.
Here's one example.

I once parsed a string obtained from a crypto exchange using WebRequest. And I parsed it usingJSON library ported bySergeyev from "high speed C++ library". And I've noticed that the speed is very unsatisfactory. There everything was done through "universal" strings.

I understood that the reason for the low speed was stringing and wanted to avoid using string-functions and wrote a function parsing directly from the uchar array. The result surprised me quite a bit. My parsing speed was.... (drum roll) 800 times faster. If parsing an entire string through JSON took 0.3 seconds, my function parsed it in less than half of a millisecond.

Here is an example of my parsing via uchar array.

[Maxim Kuznetsov]

Nikolai Semko:

Versatility is often synonymous with slowness, and with strings even more so.
Here is one example.

I once parsed a string received from a crypto-exchange using WebRequest. And I was parsing it withSergeev's JSON library, which he ported from "high-speed C++ library". And I've noticed that the speed is very unsatisfactory. There, everything was implemented via "universal" strings.

I wanted to get away from strings and wrote a function parsing directly from the uchar array. The result was surprising. My parsing speed is.... (drumroll) 800 times faster.

Here's an example of my parsing through a uchar array.

json parsing (and parsing in general) is a different story ;-)

I had troubles in a very large single-threaded scripting application working with crypto.
Suspicions fell wherever and how everything was optimized. The problem appeared to be in third-party json parser :-)

It's because "universal" libraries are designed for versatility and working with the most tricky json, but in our field there simply aren't any,
and all parcels are very short.

And yes, text parsing in MQL is a real pleasure :-). Well, it's not designed for text parsing. I mean, you can, but it's a pain in the ass.

Arrays, orders - that's the domain of MQL.