Testen von 'CopyTicks' - Seite 23

[fxsaber]

Renat Fatkhullin:

Optimal ist es, wenn Sie nur das herunterladen, was Sie selbst benötigen, und dann nur in Mikrosekunden neue Dateien aus dem nahe gelegenen Cache herunterladen.

Wenn Sie jedes Mal tiefe Abfragen machen, die nicht auf der Festplatte landen, dann ist das natürlich Ihre eigene Schuld.

Können Sie mir den Code für den optimalen Abruf der Zeckenhistorie für die erste Septemberwoche zeigen?

[Renat Fatkhullin]

fxsaber:
Können Sie mir den Code zeigen, mit dem ich am besten den Zeckenverlauf für die erste Septemberwoche abrufen kann?

Schreiben Sie es selbst, das ist nicht schwer.

Abfrage der genauen Daten und Speicherung in einem lokalen Array. Es gibt keine Optimalität, wenn man außerhalb des Caches arbeitet. Die Optimierung ist nur sinnvoll, wenn Sie die letzten 4096 Ticks aus dem Cache herunterladen.

[fxsaber]

Renat Fatkhullin:

Schreiben Sie es selbst, das ist nicht schwer.

Führen Sie eine Abfrage nach den genauen Daten durch und speichern Sie sie in einem lokalen Array.

Auf diese Weise können Sie nicht im Voraus wissen, wie viele Ticks in dem gewünschten Intervall vorhanden waren. Es gibt keine Möglichkeit, den Zählparameter zu bestimmen. Hier liegt das Problem.

Um die gesamte Geschichte seit Anfang September auszupumpen, setzen Sie count = trillion - das können Sie natürlich. Verwenden Sie dann die binäre Suche, um das Enddatum im Array zu finden und schneiden Sie es ab.

Aber diese Trilogie ist keineswegs ein technischer Ansatz. Entweder müssen wir die Funktion mit from, to überladen. Oder Indexzugriff auf die Datenbank.

[[Gelöscht]]

Renat Fatkhullin:

Eine Optimierung ist nur sinnvoll, wenn die letzten 4096 Ticks aus dem Cache geladen werden.

Von der Referenz:

Geschwindigkeitsausgabe: das Terminal speichert für jedes Symbol 4096 letzte Ticks im Cache für schnellen Zugriff (für Symbole mit laufendem Stack - 65536 Ticks)

Und etwa 65536 Ticks (mit Stack) - wäre das nicht schon optimal?

[Renat Fatkhullin]

Wir werden Verbesserungen an CopyTicks im nächsten Build vorbereiten:

• Vielleicht werden wir schnelle Caches mit automatischer Erweiterung auf 128k Ticks adaptiv machen, was es erlauben wird, einfachere Programme zu schreiben (keine Notwendigkeit, sich mit dem Herunterladen zu beschäftigen, und oft kann man das benötigte Volumen direkt vom schnellen Cache bekommen)
  
• wir werden eine zusätzliche Version der Funktion hinzufügen, so dass es möglich sein wird, Zitate mit genauen Daten von & bis zu nehmen

[fxsaber]

Renat Fatkhullin:

Wir werden Verbesserungen an CopyTicks im nächsten Build vorbereiten:

• möglicherweise schnelle Caches mit automatischer Erweiterung auf 128k Ticks adaptiv machen, was es erlauben wird, einfachere Programme zu schreiben (keine Notwendigkeit, sich mit der Wiederaufnahme des Herunterladens zu beschäftigen, und oft benötigtes Volumen direkt aus dem schnellen Cache zu nehmen)
  
• Wir werden eine zusätzliche Version der Funktion hinzufügen, um Angebote mit exakten Daten von & bis annehmen zu können

Ich danke Ihnen!

Über vollständig geladen Geschichte von & bis, wahrscheinlich, wird Null GetLastError sagen.

Beachten Sie, dass es jetzt (und mit der Einführung der von Ihnen beschriebenen Verbesserungen) extrem schwierig ist, ein Häkchen zu bekommen, das vor der Zeit war. Daher schlage ich vor, Zählung und negativ - eine Anfrage von Ticks nicht nur in die Zukunft (nach rechts), sondern auch in die Vergangenheit (wie bei von == 0) zu machen.

Dann wird es immer bequem und optimal (Ihre Implementierung) sein, den bisherigen Verlauf abzufragen.

[[Gelöscht]]

fxsaber:

Ich danke Ihnen!

Ein vollständig heruntergeladener Verlauf von & bis würde wahrscheinlich durch einen GetLastError von Null angezeigt werden.

Beachten Sie, dass es jetzt (und mit der Einführung der von Ihnen erwähnten Verbesserungen) äußerst schwierig ist, ein Häkchen zu bekommen, das vor der Zeit von war. Daher schlage ich vor, Zählung und negativ - eine Anfrage von Ticks nicht nur in die Zukunft (nach rechts), sondern auch in die Vergangenheit (wie bei von == 0) zu machen.

Dann wird es immer bequem und optimal (Ihre Implementierung) sein, den bisherigen Verlauf abzufragen.

Es ist besser, CopyTicks()-Überladungen auf einmal zu machen, wie bei anderen Copy...()-Funktionen.

[fxsaber]

Alexey Kozitsyn:
Es ist besser, die Überladungen von CopyTicks() so zu gestalten wie bei anderen Copy...()-Funktionen.

Dann müssen wir die Standardzählung und den Standard von aufgeben.

[[Gelöscht]]

fxsaber:
Dann müssen wir die Standardwerte "count" und "from" aufgeben.

Warum? Am Beispiel von CopyBuffer ergibt sich nun folgendes Bild:

intCopyBuffer(
intindicator_handle,// Indikator-Handle
intbuffer_num,// Puffernummer des Indikators
datetimestart_time,//date
intcount,// wie vielecopy
doublebuffer[]// Array, in das die Daten kopiert werden

);

Es gibt eine Zählung und von (start_time).

Sie schlagen vor, dies hinzuzufügen:

intCopyBuffer(
intindicator_handle,// Indikator-Handle
intbuffer_num,// Indikator Puffernummer
datetimestart_time,// ab welchem Datum
datetimestop_time,// bis zu welchem Datum
doublebuffer[]// Array, in das die Daten kopiert werden

);

Wir können also in beide Richtungen kopieren, richtig? Nur, statt datetime - ulong (in Mikrosekunden).

Ich werde diese Überladung in Zukunft für andere Zwecke einsetzen:

intCopyBuffer( intindicator_handle,// Indikator-Handle intbuffer_num,// Nummer des Anzeigepuffers intstart_pos,//wo wir beginnen intcount,// wie viele wir kopieren doublebuffer[]// Array, in das die Daten kopiert werden );

Das ist alles.

[[Gelöscht]]

fxsaber:
Dann müssen wir die Standardzählung und den Standard von aufgeben.

Ich habe es zuerst nicht genau gelesen... Ja, das muss ich. Na und? Wenn die Entwickler den Cache erweitern - es wird nur langsamer, wenn das Laden groß genug Zecke Geschichte, und oft ist es nicht notwendig zu tun. Und für Echtzeit-Laden wird nicht in irgendeiner Weise betroffen sein (wird aus dem Cache genommen werden).

Ich denke, es ist viel wichtiger, von Datum zu Datum zu laden, als zu versuchen, die Standardparameter zu speichern.