Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
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.
Cari avversari.
Ecco il codice dello script che:
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:
MT5:
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'è?
Dovresti almeno leggere l'Aiuto
Cari avversari.
Ecco il codice dello script che:
Risultato:
Leggere attentamente e concludere: https://docs.mql4.com/ru/basis/types/stringconst
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.
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.
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.
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.
...
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...
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.