INVESTOX-Forum

Hallo Ganesha,

Du kannst ihn reinstellen - kein Problem.
Nett, dass Du gefragt hast.

Hallo,

es gibt keinen Unterschied in der VBscript-Geschwindigkeit zwischen V5 und V6. Insofern wird es wohl am Komprimieren der Daten liegen (beim ersten Anfordern der Komprimierung seit Programmstart - in V6 kann der Zwischenspeicher bei Programmende erhalten bleiben). Um welche Komprimierung mit wie vielen Ticks handelt es sich, mit welchen Datenfeed?

Viele Grüße
Andreas Knöpfel

Zitat von »Kai«

Nur das Projekt laden mit den 2 Hilbert Indikatoren dauert 2-3 Minuten bis Investox die Charts darstellt.

Klar, das Laden eines Projektes kann durch den Titel-Zwischenspeicher ja nicht beschleunigt werden, das ist doch durch die Harddisk I/Os begrenzt (eine SSD kann hier beschleunigend wirken!). Aber dafür jede Folgearbeit, das passiert dann aus dem RAM heraus; darauf deutet auch Deine erste Erfolgsmeldung hin:

Zitat von »Kai«

danke für den Tipp, es war wohl der Zwischenspeicher, jetzt flutscht es

Zitat von »Kai«

Hardware ist prinzipiell ein neues, leistungsstarkes System auch mit viel Speicher und SSD.

Die SSD bringt nur einmalig ein bisschen Speed beim Einlesen der Tickdaten in den Cache.
Wir hatten das schon an anderer Stelle, beim FDAX dürfte das in etwas 10% sein gegenüber eine "normalen" HDD.

Memory zwar wichtig, aber in Deinem Fall würden auch 1GB reichen.
Die komprimierten Daten für den FDAX sollten in weniger als 100KB rein passen.

Wenn Du 10 Minuten Bars verwendest sind das 84 Bars pro Tag im FDAX.
Jede Berechnung in Deinem HS muss für jeden Bar durchgeführt werden.
Entsprechend muss der Backtest für ein derartiges System um rund den Faktor 100 langsamer sein.

Das fühlt sich an wie exponentiell ist aber eher linear vom Aufwand.

Zitat von »Lenzelott«

Das fühlt sich an wie exponentiell ist aber eher linear vom Aufwand.

Naja, jein.

Natürlich hat Lenzelott im Prinzip recht, aber es stimmt nur bedingt - und zwar, solange keine Trades erzeugt werden. Und wenn der Kollege im DAX z.B. sagen wir 477'618 Perioden auf 1 Minuten Basis verarbeitet (seit Sep. 2010), und daraus unter 50 Trades im Jahr (ohne Anwenderstops) generiert, stimmt die Aussage nährerungsweise.

Aber angenommen, Kai generiert aus den knapp 500 tausend Perioden 200 tausend Entries, dann führen diese vielen Entries zu weiteren 200 tausend Exit-Berechnungen, zu "Anzahl Stops x Entries" Stop Berechnungen usw. D. h. mit zunehmender Entry-Anzahl neigt ein System dazu (besonders, wenn Einstiegsbedingungen für Stops, Zusatzbedingungen usw. im Spiel sind), die Rechenzeit im Backtest exponentiell statt liniear zu verpuffen

Kai, das ist natürlich kein Investox Problem, sondern in der Natur der begrenzten Resourcen und dem Umgang mit den selben begründet, also eigentlich per logischer Schlussfolgerung zu begreifen .. und ist vor allem im Backtest ein Problem: wenn man in der Entwicklung drauf bedacht ist, dass das aktuelle Signal mit wenigen dutzend Perioden berechnet werden kann, ist so ein System trotz exorbitanter Backtest-Laufzeiten real später doch gut handelbar!

Hallo,

auch die Erhöhung der Tradeanzahl führt normalerweise "nur" zu einer linearen Erhöhung des Rechenaufwands, es sei denn, man verwendet z.B. ein Anwender-Ergebnis auf der Basis von Trades, dessen Berechnung einen exponentiellen Aufwand hat.

Doch allein die Erhöhung der Perioden von z.B. täglich auf 15 Minuten führt ja dazu (wie Lenzelott zeigt), dass die Rechenzeit von z.B. 2 Sekunden auf 2 Minuten anwächst.

Der verwendete VBScript-Indikator ist übrigens sehr komplex, mit verschachtelten Interationen etc.

Viele Grüße
Andreas Knöpfel