premetto che è da molto poco che scrivo codici su PRT, ho esperienza soprattutto su altre piattaforme, prevalentemente su Multicharts; ho scritto alcuni indicatori qui su PRT, funzionano come desidero, in live nessun problema, tuttavia quando vado a caricarli su storici di 6 mesi o un anno (in particolare su barre 100 ticks con IG) i tempi di caricamento si dilatano eccessivamente e l’attesa diventa davvero un problema. Mi è utile caricarli per fare un po’ di analisi grafica/visuale/manuale sul loro funzionamento sullo storico passato.
Mi chiedevo se esistano delle tecniche/astuzie per “velocizzarne il caricamento” senza troncare il caricamento dell’indicatore (per capirsi non cerco un “DEFPARAM CalculateOnLastBars = 200”).
Anche su questo punto (il “velocizzare il caricamento”) vorrei fare alcune precisazioni:
mi chiedevo se esiste qualcosa come il “max bars study reference” di Multicharts, in modo tale da liberare memoria via via che si avanza nella computazione (un qualche comando “magico”)
ho l’impressione che il problema sia soprattutto legato alla heap size di java, il caricamento viaggia veloce inizialmente, poi quando la memoria raggiunge all’incirca i 2Gb di memoria c’è un calo drastico nell’avanzamento del caricamento dell’indicatore. Se fossi nel giusto, ovvero che spesso la heap size di java è un collo di bottiglia, potreste per favore indicarmi un modo per cambiare questa dimensione della memoria coinvolta? Ho provato a lanciare la piattaforma utilizzando java e settando un quantitativo di memoria dalla interfaccia ma sembra che questa variazione non sortisca alcun effetto.
vorrei capire meglio, per il futuro, quali sono i componenti che solitamente impattano di più sul caricamento, per fare alcuni esempi:
utilizzare trasparenze nei colori impatta diversamente a livello di piattaforma sul caricamento oppure la piattaforma non dovrebbe percepire una differenza netta?
i comandi che è bene non utilizzare per un caricamento su storici di una certa lunghezza: ad esempio uno che so per certo, perché me lo indica PRT stesso è il “CALL”… ma ad esempio “backgroundcolor” è pesante? e il “drawtext”? So che magari sono un po’ vago, però non so… se esistesse un modo per me per capire quali comandi evitare per visualizzare indicatori su storici grossi
un’altra cosa che ho notato è la seguente, e vorrei capire un po’ meglio il perché:
ho un indicatore che utilizza dei valori a barra chiusa
lo carico su un anno di storico e ci impiega circa 15 minuti a caricare del tutto…
lo stesso indicatore lo carico 3 volte dentro una strategia utilizzando la keyword CALL in combinazione con “timeframe(100 ticks, updateonclose)”, “timeframe(200 ticks, updateonclose)” e “timeframe(500 ticks, updateonclose)” e impiega 1-2 minuti in tutto a caricare su uno storico di 1 anno…
capisco che l'”updateonclose” può fare la differenza e che probabilmente la strategia avanza e nell’avanzare non memorizza le variabili coinvolte ma solo gli ingressi e le uscite a mercato
tuttavia se anche fosse così deduco che tutto l’overhead che ho nel caricare l’indicatore è dovuto alla grafica
però non può essere solo dovuto a questo perché quando carico il “VWAP Bands” di default di PRT è velocissimo, quindi o sono io che ancora non ho colto qualche punto chiave oppure questi indicatori di default sono calcolati con delle tecniche differenti (cosa che mi viene suggerita dal fatto che non posso invocare un indicatore come “Points Pivots” utilizzando il comando “CALL”)
Uno degli indicatori in questione è il seguente, un semplice VWAP che parte ad un orario specifico invece che alla prima barra del grafico, basta provare a caricarlo su 1 anno di dati a 100 ticks di IG per osservare quanto da me descritto sopra (soprattutto al punto 2).
"max bar study reference" è lo stesso di "CalculateOnLastBars". Se non usi affatto i loop, il codice dovrebbe essere eseguito molto velocemente. Se i tuoi backtest sono lenti, è sicuramente dovuto al fatto che molte persone eseguono backtest su server IG, specialmente durante il fine settimana e nel periodo di confinamento effettivo, come sai che i backtest vengono effettuati sul lato server.
Ho provato a utilizzare un “DEFPARAM CalculateOnLastBars = 2000” all’interno del mio codice ma in questa maniera il plot del grafico è limitato solo alle ultime 2000 barre. Il plot viene troncato sullo storico e lo visualizzo solo sulle ultime 2000 barre. In Multicharts il “max bar study reference” ha uno funzionamento e scopo differente, impedisce di referenziare barre troppo vecchie dal codice e questi valori vecchi vengono rilasciati dalla memoria. In modo tale che possa avanzare nel calcolo senza intasare la memoria (soprattutto la RAM).
Ah ecco, per quanto riguarda i backtests, non sapevo che fossero fatti lato server, ora mi spiego la maggiore velocità che riscontro.
Purtroppo il codice che ho postato sopra, caricato su un grafico a 100 ticks su un anno di dati (ad esempio sul Germany 30 di IG) non è un fulmine, ma ancora gestibile: una decina/quindicina di minuti in tutto.
Tuttavia ancora non mi spiego il motivo per il quale la barra di caricamento del codice postato sopra scatta molto velocemente all’inizio e poi all’incirca a metà strada rallenta drasticamente (apparentemente quando raggiungo i 2Gb di memoria di RAM su java)… Avendo molta RAM ancora inutilizzata mi aspetterei un avanzamento più o meno lineare dell’avanzamento della barra (almeno non un calo drastico nell’avanzamento). Mi scuso ancora, per questi miei dubbi, sono soprattutto legati al fatto che ancora non conosco bene la piattaforma.
Un grazie ancora per la pazienza e la disponibilità.
Eheh davvero, in Italia anche la banda durante il giorno si vede che è parecchio sotto stress rispetto al normale…
ma un attimo, perché mi sta sorgendo un dubbio. Ho capito che i backtest sono eseguiti in remoto sui server di PRT.
Ma gli indicatori no giusto? Cioè per gli indicatori mi arrivano i dati (e quelli arrivano molto veloci, anche un anno di 100t arrivano in pochi secondi) e da quando appare la barra di caricamento (la progress bar per intenderci) è in locale dico bene?
.
