Il mio approccio. Il nucleo è il motore. - pagina 87

 
Vasiliy Sokolov:
s.w. In particolare sul tema della memorizzazione di stringhe in oggetti MT, c'è uno strano inconveniente. Se iniziate a comprimere i dati e usate caratteri non stampati nel nome dell'oggetto, in alcuni casi non sarete in grado di accedere a quell'oggetto. Il glitch è probabilmente ancora lì perché è molto specifico e non molte persone lo conoscono, ma potresti comunque imbatterti in esso.

Capisco. Solo la pratica aiuterà a capirlo definitivamente.

 
Реter Konow:

Cari avversari.

Ecco il codice dello script che:

  1. Misura il tempo di trasferimento di una stringa in un array Char, per passare la stringa a un altro programma tramite una risorsa e il tempo di recupero di una stringa da un array Char per la successiva suddivisione e il recupero di informazioni.
  2. Misura il tempo per scrivere la stringa nella descrizione dell'oggetto MT e il tempo per recuperare la stringa dalla descrizione dell'oggetto MT, per la successiva suddivisione e il recupero delle informazioni.

Risultato:


Peter, stai testando la cosa sbagliata nel posto sbagliato. Quello che stai testando dovrebbe avere circa la stessa velocità in termini di logica delle stringhe.

Hai completamente frainteso il mio messaggio.

Il mio messaggio era che dovreste smettere di usare le stringhe per passare double, long, time, int ecc. E se avete bisogno di passare del testo, allora traducete una stringa di testo in un array uchar. E tutti i dati misti di diversi tipi tramite strutture di dati unionali o array di queste strutture, convertiti in array uint tramite union, dovrebbero essere passati attraverso le risorse, e sul lato ricevente questi array uint dovrebbero essere riconvertiti tramite union alle strutture originali. Credimi, Peter, i tanga sono molto lenti, dovresti sempre evitarli dove possibile. La stringa è necessaria solo per l'output di testo e di stampa.

E nel tuo esempio hai sbagliato completamente la nozione di misurazione delle prestazioni.

In particolare tramite la proprietà OBJPROP_TEXT potete passare una stringa con una dimensione massima di 63 byte. Questo non è niente.

Anche se il tuo esempio non ha alcun senso, ma l'ho modificato in qualcosa di più corretto puramente a scopo dimostrativo e questo è ciò che ho ottenuto quando ho copiato 1000 stringhe diverse con dimensione 63 byte:

Il codice dello script è allegato. Funziona sia su MT4 che su 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

Sembra che MT5 sia asincrono, quindi il tuo metodo è 100 volte più lento e non è affatto adatto a MT5. Dovresti concentrarti sempre di più su MT5

E che cos'è?

StringToCharArray(qwerty,Arr,0,WHOLE_ARRAY);

Dovresti almeno leggere l'Aiuto

 
Реter Konow:

Cari avversari.

Ecco il codice dello script che:

  1. Misura il tempo di trasferimento di una stringa in un array Char, per passare la stringa a un altro programma tramite una risorsa e il tempo di recupero di una stringa da un array Char per la successiva suddivisione e il recupero di informazioni.
  2. Misura il tempo per scrivere la stringa nella descrizione dell'oggetto MT e il tempo per recuperare la stringa dalla descrizione dell'oggetto MT, per la successiva suddivisione e il recupero delle informazioni.

Risultato:


Leggere attentamente e concludere: https://docs.mql4.com/ru/basis/types/stringconst
Per aiutare le conclusioni:
1. 2 byte sono assegnati per ogni carattere della stringa, codifica Unicode. Non si sfrutta appieno la capacità delle corde.
2. Quando si usa la funzione CharArrayToString (e l'inverso), viene eseguita la conversione secondo la codifica dei caratteri nell'array uchar, il che fa perdere tempo alla CPU. Usate ShortArrayToString(e viceversa).
Prova, ma nota che in Unicode la stringa deve finire con zero.
 
Aliaksandr Hryshyn:
Leggere attentamente e concludere: https://docs.mql4.com/ru/basis/types/stringconst
Vi aiuterò con le conclusioni:
1. 2 byte sono assegnati per ogni carattere della stringa, codifica Unicode. Non si sfrutta appieno la capacità delle corde.
2. Quando si usa la funzione CharArrayToString (e viceversa) , viene eseguita la conversione in base alla codifica dei caratteri nell'array uchar, che consuma anche tempo della CPU. Usate ShortArrayToString(e viceversa).
Prova, ma nota che la stringa deve finire con null in Unicode.

non sono d'accordo. Abbiamo bisogno di un array uchar per la stringa come intermedio. E non c'è nessuna conversione, solo la copia di byte.

 
Nikolai Semko:

Non sono d'accordo. Abbiamo bisogno di un array uchar per la stringa come intermedio. E non c'è nessuna conversione, solo la copia di byte.

Prova a passare i caratteri cirillici. E confrontare i codici dei caratteri nell'array uchar e nella stringa, la stringa viene passata come un array ushort.
 
Aliaksandr Hryshyn:
Cercate di usare i caratteri cirillici. E confrontare i codici dei caratteri nell'array uchar e nella stringa, la stringa è come un array ushort.

So cos'è l'unicode. Ma nel nostro caso abbiamo bisogno di uchar array solo per ottenere uint array attraverso l'unione per passarlo ulteriormente attraverso la risorsa e quando si ottiene indietro la catena di recupero delle stringhe. Non ci saranno perdite. E in questo caso non abbiamo bisogno di estrarre i caratteri dall'array uchar.

La codifica può essere cambiata ed è non-unicode per default.

 
Nikolai Semko:

Peter, stai testando la cosa sbagliata nel posto sbagliato. Quello che stai testando dovrebbe avere circa la stessa velocità in termini di logica delle stringhe.

Nikolai, con tutto il rispetto, sono parole vuote per niente. Ho misurato e allegato uno script. "Il modo giusto, il modo sbagliato...", "dovrebbe avere circa la stessa velocità in termini di logica delle stringhe"... Solo parole.

Nikolai Semko:

...

Hai completamente frainteso il mio messaggio.

Il mio messaggio era che dovreste smettere di usare le stringhe per passare double, long, time, int ecc. E se avete bisogno di passare del testo, allora convertite una stringa di testo in un array uchar. E tutti i dati misti di diversi tipi tramite strutture di dati unionali o array di queste strutture, convertiti in array uint tramite union, dovrebbero essere passati attraverso le risorse, e sul lato ricevente questi array uint dovrebbero essere riconvertiti tramite union alle strutture originali. Credimi, Peter, i tanga sono molto lenti, dovresti sempre evitarli dove possibile. La stringa è necessaria solo per l'output di testo e di stampa.

Questo è esattamente il tuo messaggio che ho capito perfettamente. ED È SBAGLIATO.

Perché? - Perché si dovrebbe complicare molto il sistema di lavoro con i parametri di controllo. L'architettura di memorizzazione, passaggio e gestione dei parametri diventerà MOLTO più complicata e confusa, il che porterà a molti problemi e a un rallentamento generale.

Non capite l'architettura interna. Non sapete come i programmi interagiscono, gestiscono i valori dei parametri secondo il loro tipo e le loro proprietà. Quello che lei propone renderebbe le cose molto più complicate e confuse. E non risolverà il problema della comunicazione. Rimarrà comunque una stampella.

Nikolai Semko:

...

Inoltre potete passare una stringa con una dimensione massima di 63 byte attraverso la proprietà OBJPROP_TEXT. Questo non è niente.

Anche se il tuo esempio non ha alcun senso, l'ho rielaborato in qualcosa di più corretto puramente a scopo dimostrativo, ed ecco cosa ho ottenuto quando ho copiato 1000 stringhe diverse con dimensione 63 byte:

...

Si può passare una stringa di 64 caratteri nella descrizione di un oggetto MT. Basta così. Ho bisogno di - 20-30 linee per trasferire i dati di grandi tabelle. Senza grandi tabelle, ho bisogno di 2-3 righe al massimo.

Al momento sono interessato a MT4.

MT5 è in continuo sviluppo. Gli sviluppatori possono semplicemente aggiungere la memoria comune dei programmi MT (in modo da non dover armeggiare con le risorse) e la questione sarà rimossa.

 

Nikolai Semko:

...

Il mio messaggio era che dovremmo smettere di usare le stringhe per passare double, long, time, int ecc.

...

Come si fa a trasferire double, long, time, int ecc... ???

Abbiamo comunque bisogno di convertirlo in stringa e poi in char per scriverlo nella risorsa.

O suggerisci di usare lparam, dparam?

Cioè, sovraccaricare la coda degli eventi...

 
Реter Konow:


Che peccato. Sono fuori tema.
Asilo, secondo trimestre.
Mi annoi, Peter, con il tuo analfabetismo e la tua ignoranza e il tuo smodato senso di presunzione e diritto.
 
Nikolai Semko:


Inoltre, nelle tue misure, hai dimenticato di aggiungere il tempo per salvare e leggere la risorsa...

Quindi, anche se si scrivono 1000 righe (che è davvero meglio passare attraverso la risorsa), non si guadagna in velocità, a causa del costo di salvataggio e recupero dalla risorsa.