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
Parlando di intuizione. Voglio darvi un esempio interessante. Il mio post, stampato in questo thread https://www.mql5.com/ru/forum/95632/page12più di due anni fa:
1. Il concetto di motore grafico.
2. Concetto del nucleo grafico.
3. fasi di creazione dello studio visivo per la piattaforma MT.
4. Descrizione del meccanismo di creazione dell'interfaccia EA.
Ilmotore grafico è un programma progettato come un indicatore. Questo programma è progettato esclusivamente per la gestione dell'interfaccia utente. Esegue una serie di funzioni di base:
Il motore grafico viene aggiunto a un grafico come qualsiasi altro indicatore . Include il seguente set di finestre:
Questo, in linea di principio, è la fine del concetto di motore grafico. La cosa importante è che senza di essa il funzionamento dell'interfaccia è impossibile.
Un motore grafico è un blocco di informazioni che contiene i dati di tutti gli oggetti e le finestre di un'interfaccia, che viene registrato in un array e salvato in un file.
Questo blocco è una rappresentazione digitale dell'interfaccia grafica. Viene caricato dal motore grafico su richiesta dell'utente. Il motore grafico stesso ha un proprio kernel grafico interno che assicura il funzionamento delle proprie finestre, e all'interno di questo kernel viene fornito spazio libero per l'integrazione dell'interfaccia utente (in forma digitale) in esso. L'integrazione viene eseguita nel processo di caricamento del nucleo grafico da un file.
3. La creazione di uno studio visivo sulla piattaforma MT, da quanto ho capito, si divide in due fasi:
4. Vorrei delineare il meccanismo del processo di creazione dell'interfaccia e sollevare leggermente il velo sulla sua tecnologia. Spiegare da dove viene la facilità di creare un'interfaccia tramite un file.
Questo è il caso: il motore ha una funzione speciale che crea un kernel grafico completo basato su un singolo file con una quantità minima di informazioni di caricamento. Le informazioni di avvio in questo file sono autoesplicative e leggibili dall'uomo. È facile da scrivere e modificare. Per esempio dovete scrivere "_CREATE_NEW_WINDOW" per creare una finestra, e "_CHECKBOX" e il nome della casella di controllo, (il motore riconosce automaticamente il nome dell'elemento, come nome dell'elemento stesso e come nome del suo parametro).
Questa funzione si chiama "G_CORE_BUILDER()" e costruisce il nucleo grafico prendendo dati da due fonti principali: un file di avvio creato dall'utente e l'array "CONTENT[]" che contiene tutti i gruppi standard di oggetti inclusi nelle piattaforme di finestre e controlli. "CONTENT[]" contiene anche stati e script di oggetti. Tutto in una sola matrice. In generale, il materiale di origine da "CONTENT[]" + il file loader creato dall'utente viene utilizzato da "G_CORE_BUILDER()" per costruire il nucleo grafico con cui lavora il motore.
È incredibile quanto i termini e i concetti NON siano cambiati in due anni di duro lavoro. E le funzioni e gli array e le parole chiave sono come dice qui. Tutto è stato implementato secondo questo scenario. E questa tecnologia funziona e si evolve, nonostante ilfatto che due anni fa non avevo nessuna esperienza nello sviluppo di un linguaggio di markup.
Non ho raggiunto un vicolo cieco, non ho cambiato il concetto, non ho cambiato la direzione. Ho continuato a creare il motore, il nucleo e il linguaggio di markup esattamente come intendevo all'inizio. E la pratica conferma che la strada che ho scelto era quella giusta.
Se questa non è un'intuizione profetica, allora cosa lo è?
Cari avversari.
Ecco il codice dello script che:
Risultato:
La mia soluzione è più di 10 volte più veloce.
Aggiungete alla vostra soluzione, il tempo per salvare la risorsa e il tempo per ottenere la risorsa nell'array usando ResourceReadImage();
Nella mia soluzione, né la prima né la seconda sono necessarie.
La mia soluzione è più di 10 volte più veloce.
Peter, se lavori con le stringhe, perderai prestazioni in ogni caso. Quindi è sorprendente sentirti inseguire una prestazione mitica, anche se in origine hai scelto una soluzione inadeguata per questo: passare messaggi attraverso una stringa e poi analizzare quel messaggio.
Peter, se lavori con le stringhe, perderai prestazioni in ogni caso. Quindi è sorprendente sentirti inseguire prestazioni mitiche, anche se in origine hai scelto una soluzione inadeguata per questo: passare messaggi attraverso una stringa e poi analizzare quel messaggio.
Vasily, come si fa altrimenti a trasferire dati di tutti i tipi tra i programmi?
OnChartEvent() è parzialmente adatto.
E a proposito, misurare meno di 20 millisecondi non è affatto valido, almeno nei sistemi con multithreading preemptive. Ma anche se accetti il tuo risultato (in generale lo ammetto), ancora non ti dice nulla, perché sono i costi a tutto tondo che contano. E quello che avete misurato è solo una parte di esso.
Abbiamo bisogno di un modo universale e il più veloce. Per lavorare nel tester e per bypassare la coda di eventi OnChartEvent();
Il test mostra che è 10 volte più lento da trasferire attraverso le risorse. (senza misurare il tempo per salvare la risorsa e ottenere dati da essausando ResourceReadImage()).
La mia soluzione è l'opzione migliore nelle condizioni iniziali.
...Ma anche se accetti il tuo risultato (in generale lo ammetto), ancora non ti dice nulla, perché sono i costi a tutto tondo che contano. E quello che avete misurato è solo una parte di esso.
Vero, ma se si estrapola a più linee e ingranaggi, la mia opzione vince ancora.
Vasiliy, come si fa altrimenti a trasferire dati di tutti i tipi tra programmi?
Mappatura diretta delle strutture tramite unione ad array di byte, condivisa per l'accesso globale. Non so se questo è tecnicamente fattibile, ma se è così, la velocità sarà cosmica, perché non dovrete copiare assolutamente nulla.