Error messages

The if statement is too long

This error occurs when the indented code inside an if statement is too large for the compiler. Because of how the compiler works, you won’t receive a message telling you exactly how many lines of code you are over the limit. The only solution now is to break up your if statement into smaller parts (functions or smaller if statements). The example below shows a reasonably lengthy if statement; theoretically, this would throw line 4: if statement is too long:

To fix this code, you could move these lines into their own function:

Script requesting too many securities

The maximum number of securities in script is limited to 40. If you declare a variable as a request.security function call and then use that variable as input for other variables and calculations, it will not result in multiple request.security calls. But if you will declare a function that calls request.security --- every call to this function will count as a request.security call.

It is not easy to say how many securities will be called looking at the source code. Following example have exactly 3 calls to request.security after compilation:

Script could not be translated from: null

Usually this error occurs in version 1 Pine scripts, and means that code is incorrect. Pine Script® of version 2 (and higher) is better at explaining errors of this kind. So you can try to switch to version 2 by adding a special attribute in the first line. You’ll get line 2: no viable alternative at character '$':

line 2: no viable alternative at character ’$’

This error message gives a hint on what is wrong. $ stands in place of string with script title. For example:

Mismatched input <…> expecting <???>

Same as no viable alternative, but it is known what should be at that place. Example:

line 3: mismatched input 'plot' expecting 'end of line without line continuation'

To fix this you should start line with plot on a new line without an indent:

Loop is too long (> 500 ms)

We limit the computation time of loop on every historical bar and realtime tick to protect our servers from infinite or very long loops. This limit also fail-fast indicators that will take too long to compute. For example, if you’ll have 5000 bars, and indicator takes 500 milliseconds to compute on each of bars, it would have result in more than 16 minutes of loading:

It might be possible to optimize algorithm to overcome this error. In this case, algorithm may be optimized like this:

Script has too many local variables

This error appears if the script is too large to be compiled. A statement var=expression creates a local variable for var. Apart from this, it is important to note, that auxiliary variables can be implicitly created during the process of a script compilation. The limit applies to variables created both explicitly and implicitly. The limitation of 1000 variables is applied to each function individually. In fact, the code placed in a global scope of a script also implicitly wrapped up into the main function and the limit of 1000 variables becomes applicable to it. There are few refactorings you can try to avoid this issue:

can be converted into:

The requested historical offset (X) is beyond the historical buffer’s limit (Y)

Pine scripts calculate on every bar on the chart, sequentially, left to right, maintaining a historical buffer of values. When a script needs to use a value from a previous bar, it takes that value from the buffer. If a script tries to access a value from a bar further back than the historical buffer extends, it throws this error.

As a simple example, if your code includes a line like plot(myVar[500]), the script keeps a buffer of the last 500 historical values of the myVar variable. This buffer ensures that on every execution, the myVar variable has access to its value 500 bars before the current one.

Pine creates the historical buffer in a way that minimizes issues:

• Initially, the script calculates the historical buffers based on the data from the first several hundred bars. If historical offsets are constant, or if future offsets are not greater than the offsets found during this calculation, the script works without issues. The example above does not cause any issues because the variable is called in the global scope with a constant offset of 500. On the first iteration of the script, it is clear that the buffer size needs to be 500.
• If the script requests a value outside the buffer during calculation on historical data, the script tries to adjust the buffer to a proper length automatically. The script increases the buffer and restarts. This can happen several times until either the re-run limit is reached or the script calculates without the error.

The error can still appear on historical data, but is more likely to occur on realtime data, which is not covered by automatic buffer detection. For example, the following script works when the user first adds it to the chart, but fails with an error when the first realtime tick arrives. This behaviour can be replicated consistently by turning on the Bar Replay feature and pressing Step Forward once. This happens because on historical data, we request close[500], which establishes the size of the historical buffer as 500. When we request close[1000] on the first realtime bar, the script returns an error because the requested value is outside the buffer:

To fix this, we need to ensure the historical buffer of our variable (in this case, close) is always large enough.

The following sections describe different methods to ensure that the historical buffer is of a sufficient size.

Potential fixes

Use the ​max_bars_back()​ function

The max_bars_back() function sets the size of the historical buffer for a particular variable. To fix the issue in the example script above, we need to ensure the buffer for close is at least 1000:

Use the ​max_bars_back​ parameter of the ​indicator()​ or ​strategy()​ function

The max_bars_back parameter of the indicator() and strategy() functions provides a handy way to increase the historical buffer for all the variables inside of the script. However, increasing the historical buffer for all variables without a specific need for it negatively impacts performance. Using the max_bars_back() function is preferable because it is more precise and more performant.

Use the maximum value manually on history to force a proper buffer size

Another way to set a specific historical buffer is to call the variable on historical data with the maximum buffer required, regardless of whether it’s needed or not at the moment. For example, the script below assigns the myVar variable a close[1000] value on the very first bar of the dataset. It makes no practical difference — on the first bar, all past values are na — but because of this change, the script sets the variable’s buffer to 1000 and can then work on realtime bars without issues:

Max bars back with Pine drawings

A common reason for the historical offset error is creating drawings that are drawn on realtime data, but extend into the past. For example, the code below runs into the runtime error as soon as the first realtime tick arrives:

When the example indicator above is calculating on historical data, it does not draw any lines, and so does not call the time series at all. In this case, the time series takes the default buffer size of 300. On realtime bars, we then request the bar_index[500] value, which is converted into time[500] by the function. But the script doesn’t have a large enough historical buffer, which causes the error to appear.

In these cases, the historical buffer for the time series must be enlarged, even if the drawing functions use bar_index exclusively. The easiest fix is to call the max_bars_back() function on the time series, to ensure that its buffer is large enough:

Memory limits exceeded

The most common cause for this error is returning objects and collections from request.*() functions. Other possible causes include unnecessary drawing updates, excess historical buffer capacity, or inefficient use of max_bars_back.

Returning collections from request.*() functions

A common source of the “Memory limits exceeded” error is returning objects or collections from another chart symbol or timeframe using request.*() functions.

When requesting data from other contexts, the data for each bar is copied and stored in memory to allow the script to reference it later in the main context. This can use a lot of memory, depending on the data. Requesting large collections can easily lead to excessive memory consumption.

Let’s look at an example script where we request data to calculate the balance of power (BOP) for the symbol at a higher timeframe. Here, the request expression is a custom function that populates a persistent array with our calculated BOP values, returning the full array to the main context on each bar. We intend to use these stored array values to calculate and plot the average BOP in the main context. However, returning every array instance consumes a lot of memory, and so this script can throw a memory error on charts with a sufficiently long history:

How do I fix this?

Optimize requests and limit the data returned to the main context to ensure that only the minimum necessary data is stored in memory.

If possible, try to return calculated results directly rather than returning the collections themselves, or only return collections conditionally, when they are necessary in the main context.

Let’s consider a few common scenarios where scripts need specific data in the main context.

Return last state only

If a script needs only the last state of a requested collection in the main context: use an if barstate.islast condition to return a copy of the last bar’s collection only.

Here, we modified our script to display only the latest average BOP (a single value), rather than plotting an average line. The updated request function now returns the calculated BOP values directly for each bar, and returns the higher timeframe’s array only on the last bar:

Return calculated results

If a script needs the result of a calculation on a collection, but does not need the collection itself in the main context, use a user-defined function as the request expression. The function can calculate on the collection in the requested context and return only the result to the main context.

For example, we can calculate the average BOP directly within our request function. Therefore, only the calculated values are stored in memory, and the request expression returns a tuple (current BOP and average BOP) to plot the results in the main context:

Return the collection on some bars

If a script needs the collection itself in the main context, but not for every bar, use conditional expressions to return only the necessary collections to the main context, returning na otherwise. The logic in the main context can then address the na gaps in the series and perform its desired actions on the reduced collections.

For example, if we want to calculate the average BOP across each month instead of using a user-input length, we can return the array from the requested context only when there is a change to a new month, returning na otherwise. We then maintain the previous month’s values in the main context to keep a valid array for all intra-month bars:

Other possible error sources and their fixes

There are a few other ways to optimize scripts to consume less memory.

Minimize request.*() calls

The request.*() function calls can be computationally expensive, because they retrieve data from other contexts, which can often require significant resource usage. Excessive or inefficient requests can easily cause scripts to reach the memory limit.

This memory consumption is especially substantial for scripts requesting data from lower timeframes, where the request function returns an array of multiple lower timeframe bars for each main context bar. For example, requesting “1” data on a “1D” chart returns hundreds of “1” bars for each “1D” bar that executes the request. In the process, the script must allocate memory to store all the requested data arrays so that it can access them later in the main context, which quickly increases the memory consumption.

Programmers can reduce the number of requested expressions by:

• Removing unnecessary request.*() function calls.
• Changing the requested timeframe to a higher resolution.
• Condensing multiple requests to the same context into a single request.*() call.
• Adjusting the request.*() function’s calc_bars_count parameter to restrict the historical data points in the requested context.

See this section in the User Manual for more information on optimizing request.*() calls.

Refrain from using max_bars_back unless necessary

The max_bars_back parameter of an indicator or strategy sets the size of the history buffer for all series variables in a script. The history buffer determines the number of historical references stored in memory for the script’s built-in and user-defined variables.

By default, the Pine Script runtime automatically allocates an appropriate buffer for each variable. Therefore, the max_bars_back parameter and function are only necessary when Pine cannot determine the referencing length of a series.

If you encounter this referencing length error, ensure that you set the max_bars_back value appropriately to your script’s needs. Setting a value that’s too large can lead to excessive memory consumption, as it stores unnecessary historical data that the script ultimately doesn’t use. Read up on how to optimize using max_bars_back in our Help Center.

Minimize historical buffer calculations

The Pine Script runtime automatically creates historical buffers for all variables and function calls in a script. It determines the size of a buffer based on the historical references needed in the code (the references made using the [] history-referencing operator).

As the script runs across the dataset, referencing distant points in bar history can cause the script to restart its execution on previous bars to adjust its historical buffer size (see this User Manual article to learn more). Larger buffers in turn lead to an increase in memory consumption and can result in a runtime error. Ensure that scripts are referencing necessary historical values only, and avoid referencing very distant points in history when possible.

You can use the indicator() function’s calc_bars_count parameter or the max_bars_back() function to manually restrict the historical data capacity on a script-wide or variable-specific scale. However, be aware that these methods can also cause memory consumption issues of their own if used improperly.

Reduce drawing updates for tables

Tables only display their last state on a chart. Any updates to a table on historical bars are redundant, because they are not visible. To use the least memory, draw the table once, and fill it on the last bar.

Use the var keyword to declare table objects once. Enclose all other setter function calls in a conditional if barstate.islast block for better performance. For more about tables, see this User Manual article.

Do not update drawings on historical bars

Similar to tables, any updates to drawing objects such as lines and labels that are made on historical bars are never seen by the user. The user only sees updates on realtime bars.

Eliminate updates to historical drawings during historical bars wherever possible. For more information, see this User Manual section.

Minimize total drawings stored for a chart

Drawing objects such as lines and labels can consume a lot of memory, especially if a script recreates drawings unnecessarily.

For example, if a script draws a line from point x1 to x2, then needs to update the line’s endpoint (x2), it’s more computationally expensive to delete the existing line and redraw a new line from x1 to x3. Instead, using the setter function line.set_x2() to update the existing line’s endpoint is more efficient.

Look for ways to optimize drawing objects in a script:

• Reduce the number of redrawn objects by initializing drawing object identifiers and using their setter functions to modify properties.

• Remove unnecessary chart drawings using the delete() functions (e.g., line.delete() and label.delete()).

• Reduce an indicator’s maximum drawings limit using the max_lines_count or max_labels_count parameters.

Filter dates in strategies

The total number of trades or orders in a strategy can impact the memory consumption of a script. For large datasets, reduce the number of unnecessary historical orders stored in memory by limiting the starting point of your strategy.

You can filter the strategy’s date by adding a conditional expression that compares the bar time to a specified timestamp to only place entry/exit orders beyond a certain date.

See an example of date filtering in strategies here.