Ich sehe den 'Memory Limit überschritten. Die Studie weist X-mal mehr als erlaubt auf' Fehler

Um die kontinuierliche Verfügbarkeit von Rechenressourcen für alle TradingView User zu gewährleisten, dürfen Indikatoren und Strategien nicht mehr Speicher verwenden, als durch unser Speicherlimit vorgegeben. Wenn die von der Studie benötigte Speichermenge dieses Limit überschreitet, wird der Fehler Memory Limit überschritten angezeigt und die Studie gibt einen Runtime-Error zurück. Wenn der Fehler bei Ihnen auftritt, können Sie versuchen, Ihren Code so zu optimieren, dass er weniger Speicher verbraucht. Hier sind einige der Dinge, auf die Sie achten sollten, wenn Sie versuchen, Ihren Code zu optimieren:

  • Verwenden Sie `max_bars_back` nur, wenn es notwendig ist. `max_bars_back` ist ein Argument, das einen bestimmten history Buffer für alle Serienvariablen festlegt, die der Indikator verwendet. Standardmäßig weist Pine bereits automatisch einen passenden Puffer für jede Variable zu, so dass `max_bars_back` nur notwendig ist, wenn Sie den Fehler erhalten, dass Pine die Referenzierungslänge einer Serie nicht bestimmen kann. Für den Fall, dass Sie den Fehler erhalten, versuchen Sie, den `max_bars_back`-Wert so klein wie möglich zu machen: Wenn Sie eine Variable haben, die 400 Balken zurückgeht und einen Fehler verursacht, würde das Setzen von `max_bars_back` auf 5000 bedeuten, dass alle Variablen im Code einen 5000-Balken-History-Puffer für jeden Balken haben, was eine Menge Speicher benötigt, der für Daten verschwendet wird, die letztendlich nicht im Skript verwendet werden. Sie können in unserem Hilfe-Center nachlesen, wie Sie die Verwendung von `max_bars_back` optimieren können.
  • Versuchen Sie, so wenige `security()`-Aufrufe wie möglich zu verwenden. Die Funktion `security()` ist rechenintensiv. Bei übermäßiger Verwendung kann Ihr Indikator leicht das Speicherlimit erreichen. Dies gilt insbesondere für security()-Aufrufe, die Daten aus niedrigeren Timeframes anfordern: Wenn Sie "1m"-Daten auf einem "1D"-Chart anfordern, muss der Indikator für jeden 1D-Balken, Daten für Hunderte von 1m-Balken laden und dabei viel Speicherplatz belegen. Das Ändern des security Timeframes auf einen höheren Intervall oder das Entfernen von security() könnte helfen.
  • Der historische Puffer wird normalerweise automatisch erstellt, auch wenn Sie `max_bars_back` nicht verwenden. Variablen, die auf weit entfernte Punkte in der Balkenhistorie verweisen, erhöhen ebenfalls den Speicherverbrauch. Seien Sie sich dessen bewusst, wenn Sie Variablen, die auf Tausende von Balken in der Historie verweisen, mit dem Operator `[ ]` erstellen.
  • Wenn Sie eine Strategie schreiben, kann sich die Anzahl der Trades oder Orders auch auf den vom Skript verwendeten Speicher auswirken. Sie können den Startpunkt Ihrer Strategie einschränken, um die unnötigen Orders loszuwerden, z. B. durch Hinzufügen einer separaten Bedingung zu Ihrem Entry/Exit, die die Barzeit mit einem bestimmten Zeitstempel vergleicht. Ein gutes Beispiel für die Datumsfilterung in Strategien finden Sie hier.
  • Zeilen und Beschriftungen, die mit den Funktionen `line.new()` bzw. `label.new()` erzeugt wurden, verbrauchen ebenfalls viel Speicher. Löschen Sie nicht benötigte Zeilen und Beschriftungen mit den Funktionen `line.delete()` bzw. `label.delete()` oder reduzieren Sie die mit `max_lines_count` bzw. `max_labels_count` definierte maximale Anzahl.