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ì, non ho visto che era un grafico interno.
Beh, a giudicare dal profilo, la fonte dei freni, quando si scorre il grafico, è in questa linea:
Profilazione con scorrimento attivo:
Profilazione con movimento attivo del mouse senza scorrimento (senza LKM premuto):
ZS: Quindi la fonte dei freni non sono i kanvas dopo tutto, ma gli oggetti.
Sfortunatamente, il mio profiling di questo codice dà un vuoto. b2828.
Sfortunatamente, il mio profiling di questo codice dà un vuoto. b2828.
Sembra che non abbiano ancora finito il profiler. Anche a me capitava di avere un vuoto a volte. Ma ora funziona.
Funziona anche con questo.
Questo è l'approccio sbagliato. Soprattutto perché il visual tester ha un diverso modello di rendering ritardato, per non rallentare completamente il processo di test.
Capisco. Quindi,oltre a misurare nel tester, dovrai misurare nel grafico.
Non ho detto questo.
Ho fatto notare gli errori evidenti e ho spiegato come funziona il sistema di rendering.
Allora ho sbagliato tutto. Mi dispiace.
Sembra che non abbiano ancora finito il profiler. Anche a me capitava di avere un vuoto a volte. Ma ora funziona.
Anche questo funziona.
Anch'io non ho niente su b2830.
con il modello di eventi di Windows - anche se si muove il mouse rapidamente, il carico della CPU inizia ad aumentare, non importa quale applicazione era a fuoco
SZY: Controllato nel task manager di Win10... Non mostra alcun aumento del carico della CPU per qualche ragione, in Win7 esattamente lo stesso carico aumentava se muovevo il mouse velocemente - dubito che Win10 abbia cambiato drasticamente il modello di eventi, molto probabilmente il task manager funziona in modo diverso
Vin10. Ecco la trama quando muovo il mouse nella finestra di input di questo messaggio di testo con la LKM tenuta premuta
Qui è senza la LKM
Vin10. Ecco la trama quando muovo il mouse nella finestra di input di questo messaggio di testo con la LKM premuta
Qui è senza LKM.
non ovvio
Ecco il desktop virtuale con Win7 - se non muovo il mouse, carica la CPU del 3-4%
se il mouse si muove velocemente - 11-14% di carico
Voglio dire che la coda dei messaggi in Win ha sempre bisogno di essere processata, ma sono cicli di CPU extra - cercate su Google "C++ windows window" - qualsiasi manuale per scrivere applicazioni windows in C++ usando WinAPI, leggete lì il gestore dei messaggi
non illustrativo.
da una macchina virtuale sotto Win7 - se non si muove il mouse, il 3-4% di carico sulla CPU
se il mouse si muove velocemente - 11-14% di carico della CPU
Voglio dire che la coda dei messaggi in Win ha sempre bisogno di essere elaborata e richiede cicli extra di CPU - cerca su Google "c++ windows window".
Per metterlo in numeri più chiaramente, non sto facendo nulla - 10-15 fluttua, 17-30 quando si muove.
Ma questo dovrebbe causare il rallentamento di OnTimer di 2 volte, no naturalmente, a meno che non sia al 95-99% di carico.
Qualsiasi manuale sulla scrittura di applicazioni Windows in C++ usando WinAPI, leggete lì il gestore dei messaggi
Ma dovrebbe causare il doppio rallentamento di OnTimer, no, naturalmente, tranne che per il carico del 95-99%.
Il timer è anche un evento WinAPI, ma dubito che ogni programma MQL si iscriva al timer di sistema - emula l'ambiente MQL(macchina virtuale)
Il gestore dei messaggi prende la quota di CPU e così via, solo che non viene utilizzato quando non c'è una coda. Per i processi MT non ci dovrebbe essere un cutoff del tempo della CPU a questo carico.
C'è sempre una coda in una finestra attiva. È un'ipotesi comune come il terminale dividerà questa coda tra i grafici e poi tra i programmi MQL.
bene, alla fine - per ottenere una modalità di monopolio e non per elaborare i messaggi - non molte opzioni, il primo che viene - esclusiva applicazione modalità a schermo intero, ma questa è un'altra storia, come se la "battaglia per le risorse PC", allora avete solo bisogno di un API per andare allo scambio e scrivere la vostra applicazione, e lì registrare la finestra o non
Ok, non sono interessato a cercare il picco di carico della CPU - finché siamo in Vin, tutto può succedere, generalmente mi va bene
Il timer è anche un evento WinAPI, ma dubito che ogni programma MQL si iscriva al timer di sistema - emula l'ambiente MQL(macchina virtuale)
Non è un fatto. se vi ricordate c'era un bug con timer e numero di gestori nel terminale, suggerisce indirettamente che ogni timer in MT potrebbe essere un wineplay di sistema