Errori, bug, domande - pagina 976
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
...
È strano, ho l'immagine opposta:
Ho ottenuto questo risultato:
Forum sul trading, sistemi di trading automatico e test di strategia
Errori, bug, domande
Renat, 2013.04.27 13:32
Farò anch'io i test e scriverò i risultati.Ho completamente dimenticato che quando si testano i tag, il disegno è completamente derivato dal sistema MQL5 e disegnato nel flusso dell'interfaccia. In MQL5, vengono modificate solo le descrizioni delle etichette.
Quando si disegna una bitmap, tutto il disegno viene eseguito all'interno di MQL5 e solo un singolo BitBlt molto veloce rimane nel flusso dell'interfaccia.
Cioè, il test è completamente errato perché la mappatura dei marcatori non è testata affatto. Il refresh del grafico è un comando asincrono che invia solo una notifica al thread dell'interfaccia per il rendering. Come si può vedere dalla schermata con i costi di ChartRedraw.
Argb_normalize è meglio non usarlo, perché dà un costo extra per la normalizzazione del colore. È meglio dipingere le cose semplici con un colore puro.
Il canale alfa ha un fascino estetico. Quando il testo viene visualizzato "in modo trasparente" sopra la grafica/le palle, laconclusione ovvia da trarre è che c'è una divisione degli usi.
Se vuoi solo visualizzare un messaggio/statistica, l'etichetta di testo è più veloce. Nelcaso della creazione di controlli (come i pulsanti) - bitmap, e senza opzioni. Poi potete riempire l'intera area rettangolare con colore solido, senza canale alfa/trasparenza, senza troppa frustrazione.
La rimozione della funzione ChartRedraw() dal ciclo non è corretta, perché "l'operazione atomica" del cambio di proprietà dell'etichetta di testo non è gestita dal motore video del terminale.
Sì, esattamente lo stesso modo in cui il lavoro con l'array non è gestito dal motore video.
il problema è scoprire cosa funziona più velocemente - cambiare una bitmap o cambiare un'etichetta.
creazione di bitmap perde - questo è sicuro.
e la resa del grafico in entrambi i casi è discutibile e secondaria.
Pensate ai risultati. Vedete che 4 secondi per ciclo per cambiare le etichette ???? non ha senso.
i cambiamenti di etichette dovrebbero essere controllati puramente sul cambiamento, senza interferire con il sottosistema di rendering del grafico.
altrimenti si vedrebbero numeri comparabili con una bitmap.
Ho completamente dimenticato che durante i test delle etichette il disegno è completamente derivato dal sistema MQL5 e disegnato nel thread dell'interfaccia. In MQL5, vengono modificate solo le descrizioni delle etichette.
Quando si disegna una bitmap, tutto il lavoro viene eseguito all'interno di MQL5.
Ma l'etichetta cambia ancora più velocemente della bitmap in termini di velocità. A causa della lentezza delle funzioni GDI.
In altre parole, il test è completamente sbagliato, poiché la mappatura dei marchi non è testata affatto. L'aggiornamento del grafico è un comando asincrono che invia solo una notifica al thread dell'interfaccia da disegnare. Che è quello che si può vedere dallo screenshot con i costi di ChartRedraw.
Esattamente.
Penso che abbiamo bisogno di testare sotto alcuni compiti pesanti specifici . chi porterà a fare un compito di benchmark come questo?
- Disegnare un grafico (per esempio un'onda sinusoidale) usando un mucchio di etichette (rettangolo) e usando una bitmap.
- disegnare una tabella excel (rettangolo+etichetta di testo) e come bitmap.
e altre opzioni in cui la grafica MT può essere sostituita da bitmap.
controllare i costi delle risorse per supportare una bitmap e molti oggetti MT . + dipendenza dalle dimensioni delle aree da riempire.
Un'altra cosa che si può vedere dal test delle etichette è che c'è un'operazione di scrittura a senso unico molto economica senza etichette lette. In questo caso c'è la massima piperizzazione veloce del flusso di comandi per scrittura (usiamo volutamente un sistema efficiente in questo caso).
Ma se si mischia la scrittura con la lettura dei dati dell'oggetto, che è spesso il caso nel lavoro reale, allora la velocità scende drasticamente.
Aggiornamento: anche nell'esempio di test dei marcatori c'è un errore critico - solo una modifica va a un marcatore, non 26. Date un'occhiata alla fonte.
Cioè, il test è completamente errato, poiché non testa affatto la mappatura delle etichette.
Le modifiche ai tag dovrebbero essere testate solo per le modifiche, senza che il sottosistema di rendering del grafico venga spazzato via.
Io, ovviamente, non sono d'accordo. Argomento: è auspicabile che l'utente veda il cambiamento di situazione (statistiche) il più spesso possibile, ad ogni tick. Quindi, dopo aver aggiornato le statistiche, dovrebbero essere mostrate = ChartRedraw().
Questo è, per così dire, in termini di applicazione immediata / natura pratica della performance.
Per quanto riguarda i benchmark sferici nel vuoto - questo è opzionale.
ma il marchio cambia ancora più velocemente della bitmap in termini di velocità. A causa della lentezza delle funzioni GDI.
C'è anche unerrore criticonell'esempio di test dell'etichetta - solo un'etichetta viene modificata, non 26. Guarda la fonte.
Il testo cambia in tutte (metà) le etichette, che sono progettate per visualizzare il valore dell'indicatore, non la sua descrizione. Quando si esegue lo script, si può vedere che.
O non ti capisco. Di quale linea in particolare stiamo parlando?