High CPU Usage | Inactive User Interface | Long Time to Load Chart Data | Charts Reloading Often
This page explains solutions to the problems of: High CPU usage. The user interface of Sierra Chart becoming inactive for a noticeable period of time. Dialog windows, such as the Chart Studies window, not appearing or not appearing right away. Excessive memory use. Charts Reloading Often.
There are many possible reasons for all of these issues. This pages list the known conditions which can cause these issues and provides the solution in each case.
If the solutions listed below to reduce CPU usage and lessen the times when the user interface is inactive, are still not solving the problem, then run additional instances of Sierra Chart. For instructions to do this, refer to Using DTC Server for Data and Trading in Another Sierra Chart Instance. And refer to Sierra Chart Configuration for Most Low Response Time Trading.
Your computer should be using a minimum of a 6 core CPU with 16 gigabytes of memory for the best performance. It is also important to use SSDs (Solid-state drives). Adding more memory to your system may also help. Intel Xeon processors are available with even more CPU cores. It may also help to get more CPU cores, a faster CPU, more memory, and generally faster hardware. Although this is not necessarily the case.
For further details about solid-state drives, refer to use Solid State Drives.
If your computer is under very heavy load, and the user interface is often inactive or frozen and/or you cannot open any dialog windows (Example: Global Settings >> General Settings ), then the very first step is press the Escape (Esc) key on your keyboard and then disconnect from the data feed by selecting File >> Disconnect so you can work on resolving the problem.
Never is the solution to a performance issue going to be to uninstall Sierra Chart and reinstall. We never recommend doing that!
- 30.1 - Too Much Data Loaded
- 30.2 - Spreadsheet Study
- 30.3 - Charts Reloading Often
- 30.4 - Inefficient Study Configurations or Advanced Custom Studies
- 30.5 - Chart Update Interval
- 30.6 - Too Many Charts Visible
- 30.8 - Antivirus/Anti-Malware Software
- 30.9 - References to Other Charts / Continuous Full Recalculation of Charts
- 30.10 - Short Bar Time Frames/Periods. Include Columns with No Data.
- 30.11 - Large Data Files
- 30.12 - Intraday Data Storage Time Unit. Historical Data Record Time Frame.
- 30.13 - Split Data Records
- 30.14 - Display Continuous Time Countdown (CountDown Timer)
- 30.15 - Highlight Tools Drawings
- 30.16 - What to do if Sierra Chart is in a frozen state for an extended time due to extended high CPU usage caused by an automatically or manually opened Chartbook
- 30.17 - Rebuilding Your Chartbook
- 30.18 - Studies that use the Internal Setting: UpdateAlways.
- 30.19 - Maintaining Too Many Time and Sales Records.
- 30.20 - Transparent Draw Styles
- 30.21 - Reducing File Sizes by Using Intraday Data File Management Feature
- 30.23 - Chart Tick Size and Volume at Price Processing
- 30.24 - Spreadsheet Windows Visible
- 30.25 - Excessive Memory Use Caused By Time And Sales Records Setting
- 30.26 - Too Many Chart Drawings
- 30.27 - ACS (Advanced Custom Study) Control Bar Buttons
- 30.28 - Memory or Graphics Device Interface Object Leak
- 30.29 - Solid State Drives
- 30.30 - Controlled Order Chart Updating
- 30.31 - System Memory Not Releasing
- 30.32 - Linking Scroll Position
- 30.33 - Dotted or Dashed Lines >= 2 Pixels in Width
- 30.34 - TPO Profile Chart Letter/Block Price Increment / Volume by Price Ticks Per Volume Bar
- 30.35 - Volume by Price Study Configurations
- 30.36 - Chart Data File Error/Out of Range Value
- 30.37 - Determining CPU Load from Sierra Chart
- 30.38 - Long Time to Download Historical Chart Data
- 30.39 - Average Time to Open Chartbooks
- 30.40 - Dialog Windows Do Not Display
- 30.41 - Slow Replay Due To Back Test Modes
- 30.42 - Detached Charts
- 30.43 - Bid and Ask Depth Bars Study
- 30.44 - Performance Differences Between Versions of Sierra Chart
- 30.45 - Detailed Continuous Futures Contract Logging
- 30.46 - Market Depth Combine Increment in Ticks
- 30.47 - Use Sub Instances to Distribute Processing Load
- 30.48 - Basic Steps to Resolve Performance Issue in Sierra Chart
- 30.49 - Studies Recalculating at Earlier Index and Study Dependencies
30.1 - Too Much Data to Load or Loaded
Specifying too much data to load or loaded into one or more charts will increase the amount of time it takes for the chart data to load and for the studies on the chart to be calculated when there is a full recalculation of the studies.
The usual case which causes a full recalculation of studies is when the chart is opened as part of a Chartbook or study settings are changed.
To reduce the amount of days of chart data loaded into a chart, select Chart >> Chart Settings on the menu. Set the Use Number of Days to Load >> Days to Load setting to a smaller number. This issue primarily applies to Intraday charts. Not Historical charts. Although with Historical charts, if you are using studies on those charts that are time-consuming to calculate, then reducing the number of days in the Historical chart can reduce CPU usage.
Reducing the Days to Load will definitely decrease the amount of time it takes to load Intraday chart data.
The amount of time it takes to load Intraday chart data with a particular Days to Load setting, is affected by the number of data records in that data file. The Global Settings >> Data/Trade Service Settings >> Intraday Data Storage Time Unit affects this and also the frequency of trading for the symbol. If the Intraday Data Storage Time Unit is set to 1 Tick, and there is a lot of trading that occurs for a symbol, it will take longer to load Intraday chart data compared to a symbol that trades less frequently.
Also, take note of the information given in 30.12 - Intraday Data Storage Time Unit. Historical Data Time Frame.
When you are loading a large number of days into a chart, have a lot of charts open, and a lot of studies on those charts, then as historical Intraday data is being downloaded, this can increase CPU usage.
Therefore, when large amounts of data are being downloaded or you are re-downloading Intraday data for a particular symbol, it may be a good idea to close your Chartbooks and open a small number of charts without studies to work with while you are performing operations like re-downloading data or other operations involving managing of chart data.
This is generally not necessary. However, it can be helpful with very complex Chartbook configurations. If you do this, then when Sierra Chart is finished with downloading data, you will no longer see Downloading Historical Data on the chart, at that time go ahead and open your usual Chartbooks.
Even when a study is set to be hidden, it will still be calculated and does not eliminate the calculations. Although it does eliminate the graphics processing if it is on a visible chart.
You are able to see the full recalculation time of a study in the Chart Studies window. For details, refer to Studies to Graph. In general the full recalculation time of a study is going to be reduced by reducing the number of days loaded in the chart.
30.2 - Spreadsheet Study
The Number of Rows input for a Spreadsheet Study is set to a very high number. This potentially can cause high CPU usage when new bars are added to the chart or there is a full recalculation of studies. You may want to reduce this to 1000. Refer to the Number of Rows Input description on the Spreadsheet Study Inputs documentation page for more information about when this can cause a problem.
Another possible reason for high CPU usage is you are using the same Spreadsheet file, which is used by the Spreadsheet Study, in more than one currently open Chartbook at the same time. Refer to the Number of Rows Input description on the Spreadsheet Study Inputs documentation page for more information about when this can cause a problem.
30.3 - Charts Reloading Often
If a chart is reloading itself often, then there can be two causes of this.
One cause is because the chart is being referenced by 2 or more charts, that contain a study that refer to other charts. In this case, each of the charts that is referencing the chart that is reloading often, has different Chart Settings.
These Chart Settings include the time period per bar, Session Times, and Number of Days to Load or Date Range settings. Differences between these settings among 2 or more destination charts will cause the source chart to reload to match the settings of the destination chart. This causes continuous reloading of the chart data in the source chart being referenced by those other charts.
To determine if a chart is being referenced by other charts, select Chart >> Chart Settings on the menu. Look at the top of the Chart Settings window. If the chart is being referenced by other charts, you will see the chart numbers referencing it after Ref. by: on the title bar of the Chart Settings window.
An indication that this is occurring will be indicated by messages like this in the Message Log:
Chart #1 has tagged chart #13 for full recalculation. Chartbook: Chartbook1.Cht Chart #1 has tagged chart #13 for full recalculation. Chartbook: Chartbook1.Cht Chart #13 is performing a full recalculation because it has been tagged. Chartbook: Chartbook1.Cht Chart Settings have been synchronized between Destination chart number #13 and Source data chart number #1. Performing a chart reload of source data chart.
Other indications of this occurring is a chart switching between different time periods per bar or the cursor often changes to an hourglass.
Studies like the Difference study will refer to other charts. For example, given charts #1, #2, and #3, if studies on charts #1 and #2 both make a reference to #3, and #1 and #2 have different time periods per bar, then chart #3 will often reload and switch between different time periods per bar.
Studies like the Difference and Ratio studies make references to other charts for the necessary data they need.
The proper solution to this issue is to open another chart, and have the #2 chart refer to that new chart instead of #3. It could even be that you no longer need charts #1 and #2 to refer to #3 any longer and you just need to remove the studies that make reference to a source chart, from charts #1 and #2.
A second cause of this problem is an Advanced Custom Study which is changing one of the Chart Settings which is causing a reload of the chart. If this reloading is continuous, then the study is not functioning properly.
TPO Charts Reloading Often
Another scenario which can cause a chart to continuously reload its data is if the chart has a TPO Profile Chart study on it. This in and of itself will not cause a reloading problem, but there is a scenario where this can happen.
The TPO Profile Chart study will change the underlying timeframe per bar to 1 minute. When this happens and the chart is being referred to by another chart with a different timeframe for bar, then the chart will reload and set its timeframe per bar to be the same as the referencing chart.
After that reload completes, the TPO Profile Chart study will then set the chart back to 1 Minute per bar. This results in an endless cycle of reloading. In this case, make certain the TPO Profile chart is not referred to by any other chart.
30.4 - Inefficient Study Configurations or Advanced Custom Studies
One or more Advanced Custom Studies that you are using, is using a lot of CPU time. These are studies which are added through Analysis >> Studies >> Add Custom Study but excluding the Sierra Chart provided studies. This also includes studies from the "User Contributed Studies" DLL.
To confirm if these studies are the problem, restart Sierra Chart and on the Sierra Chart Login window, enable the Safe Mode option.
For complete details, refer to help topic 17.1.
If you no longer notice high CPU usage, then one or more of those studies was the problem. You need to contact the developer of the study or studies to correct this problem.
It is not unusual for user developed Advanced Custom Studies to use a high amount of CPU usage due to inefficient programming.
You are able to see the full recalculation time of a custom study and any study in the Chart Studies window. For details, refer to the Studies to Graph list.
During a full recalculation of a chart which happens when a chart is reloaded (like when changing the timeframe of chart bars), or when a Chartbook is opened and the studies are calculated, or when enabling and disabling Trade >>Trade Simulation Mode, then the study calculation time is going to take longer because of the full recalculation.
Sierra Chart Provided Studies
Sierra Chart provided studies can also be configured in a way which causes high CPU usage and inefficiencies as well. To determine which study is causing a problem, it is helpful to look at the full recalculation time of the study in the Studies to Graph list.
Another approach is to Remove one study at a time from the open charts to see which particular study is causing excessively high CPU usage and maybe causing a performance issue.
When you remove a particular study from a chart, and you notice a performance improvement this is a good indication, that study was causing a performance issue. You then need to look at the Input Settings of it.
Another way to reduce the calculation time is to decrease the Days to Load setting in Chart >> Chart Settings.
30.5 - Chart Update Interval
The Chart Update Interval is set to a small interval which causes increased CPU usage.
To increase the global Chart Update Interval setting, select Global Settings >> General Settings on the menu. Enter the value in the Chart Update Interval box in milliseconds. Try increasing it to 900 ms or higher.
Individual charts and Trade DOMs can override the global Chart Update Interval setting. Go to a chart and select Chart >> Chart Settings >> Advanced Settings. Set the Chart Update Interval in Milliseconds 0 to use the global setting.
If you are using a Chart Update Interval under 100 ms, then do not contact support for high CPU usage problems. Be aware that using an extreme setting like under 50 ms is not regarded as efficient and you should be aware of the potential negative consequences with CPU usage that this will cause. In other words, use these more extreme settings at your own risk!
For complete information, refer to the General Settings documentation page.
Also, refer to the 30.30 - Controlled Order Chart Updating setting. In almost all cases, Use Controlled Order Chart Updating should be disabled. It is only for use with special types of trading systems.
Using Higher Chart Update Interval for Charts Which Use a Lot of CPU Time
For charts that you know use a lot of CPU time it is recommended to use an independent Chart Update Interval for them. Go to those charts and select Chart >> Chart Settings >> Advanced Settings. Set the Chart Update Interval to a nonzero value. We recommend using a range of 1500 to 3000 milliseconds.
Or what you can do is increase Global Settings >> General Settings >> Chart Update Interval to a higher value, and in those charts that you want to update more frequently you can use a shorter Chart Update Interval for those.
Also refer to Sierra Chart Configuration for Most Low Response Time Trading section.
30.6 - Too Many Charts Visible
Having many charts visible at the same time may cause an issue. Although not typically. Try minimizing the charts that you do not need to see or reduce their overall size.
It is possible to hide a Chart window through Window >> Hide Window. Refer to Hide Window.
30.8 - Antivirus/Anti-Malware Software
Antivirus/Anti-Malware software programs can cause high CPU usage within Sierra Chart, a long time to load chart data, and longer times to download historical data.
To solve this, exclude files with a scid extension from being scanned by the Antivirus/Anti-Malware program, set the Sierra Chart folder (usually C:\SierraChart) to be excluded from scanning, or disable the Antivirus/Anti-Malware program altogether.
Antivirus/Anti-Malware programs can cause a significant increase in CPU usage if scid files are being scanned during real-time chart updating. If you exclude the scid file extension or the Sierra Chart folder from being scanned and you still notice high CPU usage, then disable your Antivirus/Anti-Malware program.
After disabling the Antivirus/Anti-malware program, it is necessary to restart Sierra Chart. You should in general not run these types of programs on a computer for trading. In our experience, Antivirus/Anti-Malware and firewall programs typically are the source of numerous problems on computer systems.
One indication that an Antivirus/Anti-malware program is causing high CPU usage is if you select File >> Close All Chartbooks and File >> Disconnect and you still notice high CPU usage by the Sierra Chart process as reported by the operating system, then this is a definitive indication that it is being caused by the Antivirus/Anti-malware program.
In some cases it is not enough to disable the Antivirus/Anti-malware program from your system and instead you must remove the Antivirus/Anti-Malware program completely from your system and confirm that is removed and confirm there are no left over Services from it. Disabling it is not sufficient. Our statements here are backed up with lots of experience. We have seen issues like this before. This is a definite step you need to take if you still notice the high CPU usage even after closing the Chartbooks and disconnecting from the data feed.
Microsoft Security Essentials : Many users of Microsoft Windows will be using the Microsoft Security Essentials anti-malware software offered by the Microsoft operating system. For users that are running Microsoft Security Essentials, it is essential that you set it to exclude the folder Sierra Chart is installed to from being scanned and also exclude scid file types.
30.9 References to Other Charts / Continuous Full Recalculation of Charts
Some studies, this includes the Difference (Bar/Single Line) and the Study/Price Overlay studies and others, will reference data on other charts.
You need to be aware of what are known as circular references. A circular reference is when two charts refer to each other. An example of this would be when Chart #1 has studies that reference Chart #2 and Chart #2 has studies that reference Chart #1. This kind of circular reference can lead to reliable behavior with the studies.
Sierra Chart should detect this kind of circular reference and will prevent any consequence from it. However, what potentially can occur is that each of these charts would be continuously updated at the Chart Update Interval set in Global Settings >>General Settings.
This is what you will see in the Sierra Chart Message Log when the circular reference is detected:
You also need to be aware of indirect circular references. An example of an indirect circular reference is: #1 -> #2 -> #3 -> #1. This will cause continuous full recalculation of the charts. Sierra Chart will not be able to detect an indirect circular reference.
If there is continuous full recalculation of charts, as is evidenced by the Message Log messages below, or you have a circular reference, remove the studies that are causing the circular reference from one of the charts or have them refer to another source chart with a timeframe per bar and with the studies that you require, but which does not reference back to the destination chart which is referencing that source chart.
A chart continuously reloading can also cause these same messages and that is explained further below.
Below is an example of what you will see in the Sierra Chart Message Log as the result of an indirect circular reference:
Chart #2 has tagged chart #1 for full recalculation. Chartbook: Chartbook253.Cht
Chart #1 is performing a full recalculation because it has been tagged. Chartbook: Chartbook253.Cht
Chart #1 has tagged chart #3 for full recalculation. Chartbook: Chartbook253.Cht
Chart #3 is performing a full recalculation because it has been tagged. Chartbook: Chartbook253.Cht
Chart #3 has tagged chart #2 for full recalculation. Chartbook: Chartbook253.Cht
Another condition which can cause the above messages is a chart continuously reloading. In which case it will tag charts for a full recalculation, that reference it. For further information about this condition and how to solve it, refer to 30.3 - Charts Reloading Often.
To determine if a chart is being referenced by other charts, select Chart >> Chart Settings on the menu. Look at the top of the Chart Settings window. If the chart is being referenced by other charts, you will see the chart numbers referencing it after Ref. by: on the title bar of the Chart Settings window.
If Sierra Chart support referred you to this help topic subsection and you are very confused by all of this and do not know what to do, then select File >> Close Chartbook to close the Chartbook you are currently using, assuming it is that Chartbook which is causing the above continuous full recalculation messages.
This should stop the above messages. If not, continue closing Chartbooks until the messages stop. Do not use the Chartbook causing those messages again and create a new one with File >> New Chartbook. The Chartbook you closed has a circular reference condition which needs to be solved if you want to continue to use it.
Efficient Use of ACSIL Functions to Reference Data from Other Charts
If you are a custom study developer and you are using ACSIL functions to get main price graph or study data from other charts, then it is important to use these functions efficiently. Refer to the scsf_DifferenceBar function in the /ACS_Source/studies6.cpp file in the Sierra Chart installation folder for an example.
30.10 - Short Bar Time Frames/Periods. Include Columns with No Data.
Using a short time frame/period per chart bar or using the Include Columns with No Data option, especially with a high Days to Load setting, will cause very long Intraday chart load times with high CPU usage and an inactive user interface. A short time period per bar includes using a time period under 1 Minute per bar, a small Number of Trades Per Bar, Volume Per Bar, or a small Range Per Bar setting.
To change these settings, select Chart >> Chart Settings on the menu. Decrease the Days to Load setting. Uncheck the Advanced Settings >> Include Columns with No Data option. And increase the time period per bar in the Intraday Bars Period frame.
An example of a problem would be if you set the Intraday chart bars to 1 Number of Trades Per Bar, try to load 30 days of data, and there is tick by tick data in the chart data file. In this case you may be waiting a long time to load up that chart. The solution is to decrease the Days to Load setting or use a higher time period per bar. If you combine this issue with the issue discussed in subtopic 30.3, then you are going to have a real problem.
Another thing to understand is that if you are using Number of Trades or Volume chart bars, and the necessary data to calculate the number of trades or volume per bar is not available, then the Days-Minutes-Seconds setting will be used instead. If that is a small setting, such as under 10 seconds, then this also can cause long load times under some conditions.
30.11 - Large Data Files
Very large data files will cause long load times when you open a chart.
To reduce the size of files automatically, select Global Settings >> Data/Trade Service Settings >> Data File Management on the menu. For complete details, refer to Data File Management.
If using a Tick by Tick Data Configuration, this will cause larger data files.
30.12 - Intraday Data Storage Time Unit. Historical Data Record Time Frame.
Using a larger Intraday Data Storage Time Unit will reduce storage space used for Intraday chart data, reduce the time to read chart data from the Intraday data file any time that occurs, such as when opening Chartbooks or changing the timeframe of the chart bars, and will speed up historical data downloads significantly when downloading Intraday data when using Data and Trading services that use the Sierra Chart historical data server.
The amount of time to load Intraday data in a chart is dependent upon the number of days being loaded into a chart, the size of an Intraday data file (file sizes can be determined through File >> New/Open Intraday Chart, and whether Volume at Price data is required to be maintained or not. Antivirus/Security software can also have a detrimental impact.
If the Intraday Data Storage Time Unit is 1 Tick, then the downloading of tick by tick data can be very time-consuming. Unless you need charts that use a bar period of less than 1 minute or you use Number of Trades, Volume, Range, Reversal, Renko, Delta Volume, Price Change, Point and Figure Bars, you definitely should use an Intraday Data Storage Time Unit of 1 Second or higher. This is good at storage space conservation, CPU conservation and download efficiency.
Even if you are using Number of Trades, Volume, Range, Reversal, Renko, Delta, Price Change bars, you probably will still want to increase the Intraday Data Storage Time Unit to 1 Second. The chart bars may not be 100% precise, but due to increased trading volumes, tick by tick data is simply burdensome on your system to work with. Therefore, you have to consider this and find what is a good balance. Sierra Chart will still produce reasonably accurate charts of these types from 1 Second data.
If you perform chart replays or you are using the Volume by Price study or other studies which require volume data in small time units, and you only use minute-based charts, then it is recommended to use an Intraday Data Storage Time Unit relatively small like 1 Second rather than 1 minute. This will still give you good performance improvements over 1 Tick.
To change the Intraday Data Storage Time Unit, select Global Settings >> Data/Trade Service Settings on the menu. Set the Intraday Data Storage Time Unit to a setting higher than 1 Tick.
After changing the Intraday Data Storage Time Unit, you may want to download all of the data again in the chart data file to get data at the higher timeframe per record. To do this, go to your chart and select Edit >> Delete All Data And Download.
Additionally, in the Global Settings >> Data/Trade Service Settings window, you may wish to reduce the Maximum Historical Intraday Days to Download setting from the default. For example, if it is 45 and you do not need that much data, you may want to reduce it to 10 in the case when you are downloading historical 1 Tick data. This will speed up the data downloading process.
If you set the Intraday Data Storage Time Unit to 1 Minute, you will notice a dramatic improvement with chart loading and overall performance. Although you do not have to go as high as 1 Minute. A good balance would be to use a setting of 2 seconds.
30.13 - Split Data Records
The Split Data Records option in Chart >> Chart Settings may increase the number of bars created in an Intraday chart when using Tick, Volume, or Range based bar charts. This potentially will cause increased chart loading times. This may especially be true when using a small number of Ticks or Volume per bar or a small Range per bar. Try disabling the Split Data Records option. Keep in mind if you disable the option, you may not have 100% constant Tick, Volume or Range charts. Although it can speed up load times.
Reducing the size of your data files as described in subsections 30.11 and 30.12 will also definitely help speed up chart loading times.
30.14 - Display Continuous Time Countdown (CountDown Timer)
When you are using the CountDown Timer study, enabling the input Display Continuous Time Countdown Based on Real-Time Clock will cause the countdown timer to be updated at the chart update interval. This can cause high CPU usage, and it is recommended that this option only be enabled on 1 or 2 charts at any given time. The CPU demand may be even higher if it is enabled on detached charts.
30.15 - Highlight Tools Drawings
When you have used the highlight tools, Rectangle Highlight, Ellipse Highlight or Angle Ellipse Highlight, the drawings created can cause high CPU usage when they are visible on the chart. This high CPU usage will be when the chart is being redrawn. The reason for this is that they use an advanced method to create the transparency.
30.16 - What to do if Sierra Chart is in a frozen state for an extended time due to extended high CPU usage caused by an automatically or manually opened Chartbook
When a Chartbook is opened automatically or manually and Sierra Chart goes into a frozen state for an extended time because the Chartbook is using the full amount of available CPU usage for an extended time, then you may want to or need to avoid using this Chartbook. In this case you may want to Rebuild Your Chartbook.
In the case of an automatically opened Chartbook, you will need to prevent this Chartbook from opening automatically so that you can start Sierra Chart without it going into a frozen state.
The first step is to exit from Sierra Chart. If Sierra Chart is in a frozen state, you will need to terminate the process. This can be done through the Windows Task Manager.
Start Sierra Chart again. On the Login window press the Cancel button once to stop the login process. Enable the Safe Mode option and disable the Open Files on Startup option. This will prevent Chartbooks from automatically being opened and prevent the loading of custom studies which could also be the source of the problem. For detailed instructions, refer to Using Safe Mode. After this continue with the Login process.
It is then recommended that you simply rebuild a new Chartbook because there is something in that Chartbook configuration which is using high CPU usage for an extended time or it could be caused by a custom study. However, read further in this section to understand the possible reasons for the problem.
There are several reasons for this problem. There could be certain chart or study settings which are causing high CPU usage for an extended time and is freezing Sierra Chart.
There could be some kind of data error in the chart data file which is causing an unusual problem with certain types of bar period types.
The problem could be caused by custom studies from outside developers which will not be loaded when using Safe Mode. So you can try opening the Chartbook again manually through File >> Open Chartbook and see if you encounter the problem now that you are using Safe Mode.
One of the reasons for high CPU usage causing a Chartbook to freeze could be that the Tick Size is not set correctly and there is an excessive amount of Volume at Price data. This not only will cause a long time to build that data, but it will cause the primary thread to freeze when the primary thread is building that data or studies are using that data. For more information, refer 30.23 - Chart Tick Size and Volume at Price Processing.
When a chart is being loaded, the building of the Volume at Price data happens on a background thread. But it also happens on the primary thread when historical data is being downloaded gradually.
In the case of where a chart data file is causing a problem, in most cases is going to be an Intraday data file. Instead of avoid using the Chartbook which is freezing Sierra Chart, what you can alternatively do is delete the Intraday chart data file or files as explained below.
- Select Global Settings >> General Settings. Make a note of the file path in the Data Files Folder box.
- Select File >> Exit.
- Go to the Sierra Chart Data Files Folder on your system that you made a note previously.
- Locate the Intraday chart data files which are actively being used. The name of the file for a symbol will be the symbol and it will have a SCID extension.
- Delete the file or files.
- Start Sierra Chart again and and then try opening the Chartbook again. Fresh Historical Intraday data will be downloaded from the server again.
30.17 - Rebuilding Your Chartbook
If you have reviewed all of the issues and solutions on this page and still have not found any reasonable solution to your high CPU usage problem and when you close your Chartbook or Chartbooks with File >> Close All Chartbooks, the CPU usage goes down to normal, then obviously there is something you are doing in one or more charts in those Chartbooks which is causing high CPU usage.
In this case it is then recommended that you rebuild a new Chartbook in order to start from a completely simple and clean state. Gradually as you rebuild your Chartbook, you should identify what is causing the high CPU usage when you begin to notice an increase in CPU usage from the particular settings and studies you are using.
For the charts in this new Chartbook, set the Days to Load setting in Chart >> Chart Settings to a small value.
30.18 - Studies that use the Internal Setting: UpdateAlways
Studies have an internal setting called UpdateAlways. When this is set to true, then the study will be continuously calculated and the chart window will be redrawn every chart update interval. However, the minimum interval is no less than approximately 300 ms when this setting is true. The only two studies that are built into Sierra Chart that use this are Countdown Timer, used only in some cases and discussed in help topic 30.14, and the SC Woodies Panel. What this setting means is that you will have higher CPU usage when using studies that use this setting and you will have higher CPU usage than normal even when disconnected from the data feed.
30.19 - Maintaining Too Many Time and Sales Records
In Global Settings >> Data/Trade Service Settings, if you have the number of Time and Sales records to maintain set to a large number like more than 50,000, then this is definitely high and potentially, although not necessarily, can increase CPU usage. It's recommended that if this is causing higher CPU usage, then reduce it to a smaller number.
30.20 - Transparent Draw Styles
If you are using the Transparent Draw Styles with a study or using the Transparency option with the Volume by Price study, then this will increase CPU usage. This is something to be aware of. The level of transparency can be controlled under Global Settings >> Graphics Settings. Whether this makes any difference with CPU usage, is not known.
30.21 - Reducing File Sizes by Using Intraday Data File Management Feature
One solution to this issue is to reduce the size of these files by compressing older data in them by using the Intraday Data File Management feature.
It is strongly recommended to use this feature for older historical data if you have long Intraday chart data loading times.
30.23 - Chart Tick Size and Volume at Price Processing
When using studies that rely on the Volume at Price data, which include the Volume by Price, Numbers Bars, TPO Profile Chart, Volume Value Area Lines, TPO Value Area Lines and some other studies, it can potentially take an extended time to load chart data from the chart data file due to the Volume at Price data processing.
Another problem is that there could be high CPU usage and potentially freezing, during real-time chart updating due to potentially excessive volume at price processing.
This can be true when you have tick by tick data in the chart data file.
If the chart Tick Size in Chart >> Chart Settings is incorrectly set, and is too small, this can dramatically increase the time to load chart data and also increase memory use.
This type of issue is especially a problem with crypto currency markets where the chart Tick Size may be set to a small value and as a practical matter it is just too small. So you must increase it dramatically like sometimes 100 or a 1000 times larger.
Select Chart >> Chart Settings. Press the Apply Global Symbol Settings button to automatically set the Tick Size for known symbols. If it is still not set correctly, then Update the Symbol Settings.
After updating the Symbol Settings, apply them to the chart again using the Apply Global Symbol Settings button on the Chart Settings window.
If the symbol is not defined in the Global Symbol Settings or it needs to be manually increased, then you will need to manually set the Tick Size in Chart >> Chart Settings. When you manually set the Tick Size make sure that Auto Set from Data Feed is disabled on the Chart Settings window.
Having an incorrect or too small of a Tick Size can also cause the chart to scroll slowly and result in high CPU usage and also high CPU usage during real-time updating of a chart.
Additionally, even when the Tick Size is set correctly, if there are a wide range of prices containing a large number of price ticks (based upon the chart Tick Size setting), this will increase the amount of time to load chart data, cause high CPU usage during real-time chart updating and cause the chart to scroll slowly. In extreme cases this will cause freezing of Sierra Chart. This is especially true with Historical Daily charts, higher timeframe per bar charts, and crypto currency symbols.
In the case of the foreign exchange market symbols, you will need to avoid using too small of a Tick Size and increase the Tick Size setting in Chart >> Chart Settings.
Or increase the Volume at Price Multiplier setting in Chart >> Chart Settings in the case of when charting a foreign exchange cash market symbol or in the case of Historical Daily Charts.
If the Days to Load setting in Chart >> Chart Settings is set too high, this will increase the time to load chart data when using any study that relies on the Volume at Price data.
When using studies that require the Volume at Price data on Historical Daily charts, then this will definitely slow the process of loading the Historical Daily data from the chart data file and will freeze the Sierra Chart user interface during the process of loading the data from the chart data file. The solution to this kind of problem with Historical Daily charts is to increase the Volume at Price Multiplier setting in Chart >> Chart Settings. It is recommended to use a minimum setting of 5 or even as high as 100 if necessary.
30.24 - Spreadsheet Windows Visible
While it is not a problem having a Spreadsheet window visible (these are the windows that are opened with File >> Open Spreadsheet or automatically opened by one of the Spreadsheet studies), if there is frequent updating of one of the visible sheets in a Spreadsheet such as by the Spreadsheet Study, then this will contribute to CPU usage and if you have many Spreadsheets visible, then that is even more CPU usage. The simple solution is to minimize the Spreadsheet window if you are not looking at it, if it's contributing a significant amount to CPU usage.
30.25 - Excessive Memory Use Caused By Time And Sales Records Setting
Select Global Settings >> Data/Trade Service Settings on the menu. If the Time and Sales >> Records is over 10000, then this can cause high memory use. If it's significantly higher, then your memory usage can be very very high. Reduce it to a smaller number and reconnect to the data feed.
30.26 - Too Many Chart Drawings
If you have hundreds of chart drawings (Lines, Rays, Text drawings, Price Retracements, Rectangles, ...) on a chart, then this can cause high CPU usage and sluggish chart performance.
Reduce the number of Chart Drawings on the chart by deleting some of the drawings. There are several ways this can be done including using Tools >> Manage Chart Drawings Window.
Refer to Erasing Chart Drawings.
30.27 - ACS (Advanced Custom Study) Control Bar Buttons
When using one of the Global Settings >> Customize Control Bars >> Control Bar # >> Tools - Advanced Custom Study Buttons (appears as CS# on the Control Bar), this button is been enabled on the Control Bar (this will be indicated by one of these buttons being selected), there is a custom study on the chart which has set sc.ReceiveMousePointerEvents= true, the Pointer or Chart Values Tool is active, and your Pointer is moved around the chart window, this can result in high CPU usage.
30.28 - Memory or Graphics Device Interface Object Leak
A memory leak in a custom Sierra Chart study or from some other software component running within the address space of Sierra Chart, will cause high memory use and slow Sierra Chart performance.
To see if there is a memory leak, start the Windows Task Manager. Go to the Processes tab. Select View >> Select Columns on the menu. Make sure the Memory - Working Set column is enabled. Press OK.
Locate the SierraChart.exe process in the list and see if the Working Set memory is increasing at an obvious rate or the memory use is very high.
In either of these cases, this is an indication of a possible memory leak. While a memory leak could be caused by Sierra Chart itself, this is extremely unlikely. Although keep in mind as Sierra Chart continues to run for an extended time, Intraday charts will use gradually more memory over time but this is a small increase over long spans of time.
In almost all cases excessively increasing memory is an issue with a custom study you are using or some other software component running within the address space of Sierra Chart using a lot of memory.
It is also known that when Sierra Chart is reading Intraday files, the operating system can cache the data and this will cause an increase in memory use which may not be released until Sierra Chart is exited. This increase in memory can also be caused by drivers which are monitoring files.
To prevent custom studies from being used if they are the cause of the memory leak, run Sierra Chart in Safe Mode.
A Graphics Device Interface object leak is something that is very rare, but has occurred in some cases. To determine if there is a GDI object leak, start the Windows Task Manager. Go to the Processes tab. Select View >> Select Columns on the menu. Make sure the GDI Objects column is enabled. Press OK. Locate the SierraChart.exe process in the list and see if the GDI Objects count is increasing. If you notice it increasing, let Sierra Chart support know.
30.29 - Solid State Drives
For the very best performance it is recommended that Sierra Chart be installed on a dedicated solid-state storage drive (storage device) on your system. Only Sierra Chart should be on that particular drive. It should not be used for any other purpose.
Solid-state drives are considerably faster than hard drives. This will greatly improve the performance of Sierra Chart especially with loading Intraday chart data. And also ensures the best performance for Sierra Chart because no other program will be using that drive.
Another reason for this is when there are a lot of file I/O operations going on related to Sierra Chart, you do not want the operating system or other programs affected. For example, there will be a lot of data read from the storage drive when Intraday data is being read from a chart data file.
For example, you can have a very high performance system with solid-state drives and when a lot of Intraday charts are being opened at once, that could cause your system to freeze because Intraday data is going to be read at a very high rate from the storage drive due to the performance of the system and that is going to block I/O operations being performed by the operating system and other programs causing your system to freeze at times.
We are not referring to a drive partition here. We are referring to a separate physical storage device on your system dedicated for the use of Sierra Chart only.
It is recommended to use a solid-state drive and in particular a NVME storage drive. For further details, refer to NVMe SSDs: Everything you need to know about this insanely fast storage.
30.30 - Controlled Order Chart Updating
When Global Settings >> General Settings >> General 2 >> Use Controlled Order Chart Updating is enabled, then all of the charts within a Chartbook are updated and calculated at once, rather than separately if it is disabled. This can result in the user interface of Sierra Chart momentarily freezing while this is happening.
This option should only be enabled if required.
30.31 - System Memory Not Releasing
Sierra Chart is very memory efficient. It uses the absolute minimum amount of memory that is possible based upon what you are doing within Sierra Chart.
Memory is released by charts when they are closed and prior memory use within a chart is released when a chart is reloaded (Chart >> Reload and Recalculate).
To see what memory Sierra Chart is using, start the Windows Task Manager. Go to the Processes tab. Select View >> Select Columns on the menu.
Make sure the Memory - Working Set column is enabled. Press OK.
Locate the SierraChart.exe process in the list and look at the Working Set(Memory) column to see the memory use specifically for Sierra Chart.
If you notice your overall system memory use is high, this is from the operating system or other programs running on your system.
There are at least two possible explanations for increased memory use. The operating system may have cached the Intraday data read from Sierra Chart files. This is something Sierra Chart has no control over.
Another possibility is that anti-malware/antivirus software could be using excessive amounts of memory when it scans Sierra Chart data files. One way to isolate this as a problem is to restart your computer into Safe Mode with Networking Support to prevent this anti-malware/anti-virus software from loading and see if the excessive memory use goes away. If so, the problem is being caused by that software.
If there is a particular chart or charts within a Chartbook which are using a lot of memory, then first remove studies from those charts one by one to see if the memory use goes down significantly. Next, close those charts one by one and see if memory use goes significantly down. This will help you isolate where the problem is with high memory usage.
30.32 - Linking Scroll Position
When using the Chart Linking feature and linking the Scroll Position, that when scrolling charts, Then this will increase CPU usage and possibly could cause sluggishness with scrolling the chart.
Therefore, if linking the Scroll Position for more than two charts, and scrolling a chart that uses linking is sluggish, then try disabling the Scroll Position Chart Linking option to see if that solves the problem.
30.33 - Dotted or Dashed Lines >= 2 Pixels in Width
For any line drawn in Sierra Chart whether Study Subgraph lines, Order lines, Chart Drawing lines, or Grid lines, if the line width is greater than or equal to 2 pixels and they have a Line Style of any of the following:
Then these are drawn with what is called a geometric pen. This is an operating system drawing object.
Lines drawn with a geometric pen uses more CPU usage. For example, if a chart has a horizontal Grid using a line width of 2 pixels or more, a Line Style of Dot, and there are a lot of horizontal lines on the chart from the Grid, then as you scroll the chart, you will have a noticeable sluggishness which is caused by the high CPU usage from the geometric pen.
Therefore, the solution to this is to set the Line Style to Solid for efficiency.
30.34 - TPO Profile Chart Letter/Block Price Increment / Volume by Price Ticks Per Volume Bar
If there are a large range of prices displayed in the current view of a TPO Profile chart, it is possible that there are a large number of letters/ blocks displayed for TPO Profile.
When the chart is scrolled or when the chart is updated, the drawing of these TPO Profiles will be slow if there are a very large number of letters/blocks currently displayed.
There are two solutions to this problem.
The first solution is to increase the Letter/Block Price Increment in Ticks Input setting with the TPO Profile Chart study to a higher number. This may be especially important with Forex charts, which use a small Tick Size to begin with.
Increase the Letter/Block Price Increment in Ticks 1 at a time until you get a good balance between detail and minimum of CPU load.
The second solution is to set the Sub Period Price Display Style Input setting to Horizontal Bars. This will significantly reduce CPU usage of the TPO Profiles and allows you to continue to use a more detailed Letter/Block Price Increment in Ticks setting of 1 or 2.
In the case of when using the Volume by Price study, there can be the same kind of problem where there are too many volume bars per Volume Profile causing a performance issue. In this case, increase the Ticks Per Volume Bar Input setting.
30.35 - Volume by Price Study Configurations
There are certain Volume by Price study configurations which can cause high CPU usage and make the overall performance of Sierra Chart sluggish or cause momentary freezing.
Newer versions of Sierra Chart starting approximately at version 1290, have performance improvements with the Volume by Price study. If you are running a version earlier than this, then update Sierra Chart to the current version.
The type of Volume Profiles which can cause high CPU usage would be long-term single profiles which are calculated relative to the last Date-Time in the chart. An example would be a 3 months or greater Volume Profile with a Volume Graph Period Type of One Period at End of Fixed Time Length.
The solution to this is to change the Volume Graph Period Type to From Start Date-Time to End and specify a Start Date and Start Time for the Volume Profile. This makes it efficiently calculated.
For further information, refer to Volume by Price Settings.
30.36 - Chart Data File Error/Out of Range Value
A Historical Daily or Intraday chart data file that contains 80 data error or out of range value, can cause a long time to load chart data, excessive memory use and/or a long time to calculate studies. All of this can cause Sierra Chart to freeze for a period of time.
This is generally true when the Volume at Price data is being maintained for the chart. This is the case when using any of the following studies:
- Volume by Price
- Volume Value Area Lines
- Numbers Bars
- Numbers Bars Calculated Values
- TPO Profile Chart
- TPO Value Area Lines
Or any other study that requires the Volume at Price data.
The solution to this in the case of a Historical Daily chart is to fully re-download the data in the chart by selecting Edit >> Delete All Data and Download. Although this assumes that the server has the correct data.
Assuming the server has the correct data, a comprehensive solution to a data error in an Intraday chart data file is to delete the Intraday chart data file following the Deleting Intraday Chart Data file instructions.
30.37 - Determining CPU Load from Sierra Chart
This section describes how to determine what the load Sierra Chart is placing on your system CPU and if the maximum available CPU time used by the Sierra Chart primary thread of execution, has been reached.
Sierra Chart does use multiple threads, but the additional threads are for loading Intraday data and for some other specialized purposes. However, most processing which is occurring during real-time updating is on the primary thread.
Go to the Performance tab of the Windows operating system Task Manager. Look at the CPU Usage History.
Make a note of how many windows there are showing CPU usage history. Refer to the image below.
Usually you will see anywhere from 2 to 8 windows. Each of these represents a CPU core. Divide 100 by the number of cores there are. This is going to be the maximum percentage a thread of a process can use. Make a note of this calculated percentage for the next step.
Look at the Processes tab of Windows Task Manager to determine the CPU load from the SierraChart.exe process. The CPU usage will be displayed in the CPU column which shows CPU usage by the process as a percentage.
If you see the SierraChart.exe process at or close to the percentage you made a note of previously, then Sierra Chart is under a very heavy processing load and Sierra Chart may not be processing real-time data fast enough. This can contribute to a data feed lag. If you notice the CPU usage is low, then the issue is not due to too much of a CPU load.
If it appears as though lagging or other slow performance issues is because your computer is not running Sierra Chart fast enough, then the next step is to review all of the solutions listed on this page
Long Time to Download Historical Chart Data
If it is taking a long time for the historical chart data to downloaded for a particular chart, then there can be more than one reason for this.
If you notice that Sierra Chart is in a frozen state and can not cannot be interacted with at times, then the issue is due to one of the other subtopics on this page. Refer to the list in the Introduction section.
Otherwise, this could be caused by a network connectivity problem. In this particular case, refer to Error when Downloading Historical Intraday Data from the Sierra Chart Historical Data Server. The solution could be to use Port 80 as explained.
Average Time to Open Chartbooks
The amount of time for a Chartbook to open depends upon how many charts are in it, the number of days being loaded in Intraday charts in the Chartbook, and the calculation time for studies.
A reasonably efficient Chartbook should open in less than 5 seconds. If a Chartbook is taking 30 seconds or longer to open, then this is considered a very long time and not acceptable under usual conditions.
The first thing to do is to refer to the following subsections on this page improve performance.
- 30.1 - Too Much Data Loaded
- 30.4 - Inefficient Advanced Custom Studies
- 30.8 - Antivirus/Anti-Malware Software
The next step is updating of your computer hardware. Your system should have a Solid State Drive, a 6 core CPU at a minimum, and a fast CPU clock speed.
30.40 - Dialog Windows Do Not Display
A dialog window is a window which contains various controls primarily to set global or chart specific settings. An example of a dialog window is the Chart Settings window opened with Chart >> Chart Settings. Another example is the Global Settings >> General Settings window.
When opening a dialog window in Sierra Chart, if it does not appear, then there can be different reasons for this. The first thing to do is to press the Escape (Esc) key on your keyboard to cancel the dialog operation so that you can interact with Sierra Chart.
The primary reason for this problem is the operating system level resources to create a dialog window are insufficient. This is an operating system level problem. It would help to close programs on your system. Also try reducing the number of open charts within Sierra Chart in particular detached charts which can be reattached to the main window. This can be done by going to the detached chart and selecting Window >> Detach/Attach Window.
This problem could also be because your computer or Sierra Chart is under a very heavy load, and prevents the dialog window from becoming visible. One thing you can do that should immediately reduce the CPU load is disconnect from the data feed by selecting File >> Disconnect. Also, increase the Chart Update Interval.
As a last resort you may need to restart your computer to overcome this issue with dialog windows not appearing.
Once again, this is a Windows operating system level problem and not some kind of problem within Sierra Chart itself.
In regards to the above, what we have found resolves the issue is force the immediate display of the dialog when it is opened. In the latest versions of Sierra Chart, this has been implemented for most dialogs but this causes the dialog to appear at the top left of the parent window rather than centered. If you continue to have this problem of the dialog windows not appearing, then let Sierra Chart know what particular dialog you are having a problem with and we will implement this workaround by forcing the immediate display of it.
Gradually the dialog windows in Sierra Chart will be replaced with a common resizable window to view and adjust settings. This is expected to be completed by June 2020. These new windows will not use the Windows operating system dialog functionality, and will be fully created by Sierra Chart and will work around this kind of issue.
30.41 - Slow Replay Due To Back Test Modes
When replaying a chart or charts, and the Replay Mode on the replay control panel opened with Chart >> Replay Chart >> Replay Chart (Control panel) is not set to Standard Replay, there will be a significant number of additional calculations which are performed during the chart replay which will increase CPU usage and and cause the user interface to become less responsive.
If you are not performing any type of back testing of an automated trading system, then set the Replay Mode to Standard Replay.
You need to stop the chart replay first and start it again for any changes to the Replay Mode to go into effect.
30.42 - Detached Charts
We have observed that detached charts consume more operating system User objects and increase CPU usage. The reason for this would be strictly due to the operating system and is not related to Sierra Chart.
It is therefore recommended to keep charts attached and if you want to separate charts from the main window to instead use multiple instances of Sierra Chart. Refer to Using DTC Server for Data and Trading in Another Sierra Chart Instance (New Instances) for instructions.
30.43 - Bid and Ask Depth Bars Study
The Bid and Ask Depth Bars study potentially can use a lot of CPU time if there are many market depth levels it needs to process, like greater than 100. For instructions to reduce CPU usage for that study, refer to Improving Performance of this Study.
30.44 - Performance Differences Between Versions of Sierra Chart
If you seem to notice reduced performance in one version of Sierra Chart compared to another version, then understand that there can be many reasons for this.
First understand, reporting this to Sierra Chart support, in general is not helpful because we are not in a position to know what the cause is from. It would take an immense amount of analysis for us to really start to analyze this based upon what you are doing with Sierra Chart and your Sierra Chart configuration including its charts and studies and so many other things. This is simply something we will not do. So in general when we get these reports, they are almost never analyzed and are referred to this help topic.
If we are aware of a change in the program which may have some improvement in capabilities, but be more processing for that particular function, we will suggest that might be the cause. Although a change like this is rarely the case.
In general newer versions of Sierra Chart deliver higher performance as compared to older versions because there are continuous performance enhancements that are made throughout the program. Therefore, a report of lower performance is completely contrary to what we know to be true. So that is why when someone mentions a performance issue, we know that it must be something specific to their system or configuration and something unusual going on.
Now if you notice a performance issue after updating from a version 2 or more years ago, then yes it is possible there could be something that is less efficient perhaps may be related to formula processing due to more functionality available with that but this has been optimized as well.
You may be mistaken to believe the problem is with a newer Sierra Chart version, when the problem can be with your system itself. The capabilities of your computer system, and the current state of the system, can make Sierra Chart perform poorly. A possible solution is a restart of your system. We have heard this can resolve performance issues.
The particular configuration that you are using in Sierra Chart, related to the charts and studies and various other functionalities of the software, and the data loaded in the charts, could be on the margin of the capabilities of your system, and due to a small change in the structure of a new version of Sierra Chart, then makes the performance issue noticeable.
It is important to also understand Sierra Chart offers a broad amount of functionality and very advanced functionality. We offer Sierra Chart at very low prices. When you start doing a lot of things with the program, and creating a lot of charts and working with various studies in different configurations, you cannot expect us to be a burdened, with what you have done with Sierra Chart when you have a problem. This is for you to resolve. Not us.
This is why we have this page here to give you guidance on things to check. So it is a faulty analysis to think it is our responsibility to help you at no cost. We will not do that. You need to help yourself and we give you the information you need to help yourself through this page and the other documentation on this website.
30.45 - Detailed Continuous Futures Contract Logging
When the Detailed Continuous Futures Contract Logging option is enabled, then this causes an excessive amount of messages to be added to the Message Log.
Disable this option to reduce CPU usage related to these messages, during the loading of a Continuous Futures Contract chart.
30.46 - Market Depth Combine Increment in Ticks
When using a Market Depth Combine Increment in Ticks in the Chart >> Chart Settings of 1 or greater, this can increase CPU load when there are a large number of market depth levels for the symbol, like over 100.
30.47 - Use Sub Instances to Distribute Processing Load
If you have charts open especially ones that present a high graphics and/or calculation load, then you should run those on a sub instance of Sierra Chart to minimize the load on the main Sierra Chart instance which may be used for trading or may be causing Sierra Chart to be less responsive.
Use as many sub instances you need to distribute the load based upon the complexity of your chart setup.
For complete documentation, refer to Using DTC Server for Data and Trading in Another Sierra Chart Instance (New Instances).
30.48 - Basic Steps to Resolve Performance Issue in Sierra Chart
The following are the first items to go through, to resolve a performance issue you are having in Sierra Chart where the user interface is frozen at times or less responsive.
We need to make it clear, that Sierra Chart is a very powerful program that provides a lot of functionality and capabilities. Many of our users have many tens of or ~100 charts and a lot of complexity with those charts with the Chart Drawings and Studies on them.
The prices for Sierra Chart are kept very low. When a user has a performance issue in Sierra Chart, it is your responsibility to review the information on this page, and implement the recommendations and resolve this problem on your own.
We cannot be exposed to all of the complex set ups you have done over time and only you fully understand, and resolve this for you during a remote assistance session. We do not have the time, the inclination, or the resources for this and more importantly this is not included in the Sierra Chart prices. And besides this takes away time from our software development.
When the markets are more volatile, and there is a wider price range in a day, some studies can have longer calculation and drawing times. Although this depends upon the Input settings of the study. Studies that use the Volume at Price data will take longer to calculate and draw. This is one reason why you can notice a performance issue with increased market activity.
This would be resolved by reducing the number of days loaded in the chart, increasing the Tick Size of the chart, increasing the Tick Size related study Input like the Ticks per Volume Bar (Volume by Price study), using sub instances, increasing the Chart Update Interval, and obtaining faster computer hardware.
- First if Sierra Chart is in a frozen state for an extended time when opening your Chartbooks, then restart Sierra Chart, and disable Open Files on Startup on the Login window. Do not use your existing Chartbooks. For more details, refer to 30.16 - What to do if Sierra Chart is in a frozen state for an extended time due to extended high CPU usage caused by an automatically or manually opened Chartbook.
- Run Sierra Chart in Safe Mode. This is a mandatory step. Refer to the Using Safe Mode instructions.
- Select File >> Disconnect to disconnect from the data feed and make it easier to perform the following steps if you already have a significant performance issue. This is to eliminate the charts from updating and should have an immediate performance benefit while disconnected.
- Increase the global Chart Update Interval setting to 1000 ms. If charts have a nonzero Chart Update Interval less than this value, then set those to 0. For complete documentation, refer to 30.5 - Chart Update Interval.
- Use multiple instances of Sierra Chart to distribute processing load. Refer to 30.47 - Use Sub Instances to Distribute Processing Load.
Also refer to Sierra Chart Configuration for Most Low Response Time Trading.
- Check study calculation times for each chart. Refer to 30.4 - Inefficient Study Configurations or Advanced Custom Studies.
The basic solution is going to be adjusting study Inputs appropriately which may reduce calculation time based upon the particular study and also reducing the Days to Load setting in the Chart Settings.
In the case of studies that use Volume at Price data ( Volume by Price, TPO Profile Chart, Volume Value Area Lines, TPO Value Area Lines, Volume Weighted Average Price), to reduce calculation time it is recommended to increase the Tick Size setting of the chart. For example if it is .25, then increase it to 1. Even if you do not want to do this, do it anyway to see if it makes a performance improvement.
Alternatively, each individual study in most cases will have an equivalent setting. For example, with the Volume by Price study you would want to increase the Ticks per Volume Bar Input to 4.
- Increase chart bar spacing to reduce graphics load.
- Use OpenGL but this is still considered a beta and could have stability issues.
- Increase the Intraday Data Storage Time Unit to 1 Second. For complete documentation, refer to 30.12 - Intraday Data Storage Time Unit. Historical Data Record Time Frame.. Be sure to re-download the data in the chart to store data at the larger unit which is more efficient. This will decrease Intraday chart data loading times.
- Install Sierra Chart on a dedicated solid-state drive. This is really important. Refer to 30.29 - Solid State Drives.
- There are other detailed items on this page covering specific subtopics to help improve Sierra Chart performance and reduce CPU usage. Refer to the Introduction section for the list of all of these.
30.49 - Studies Recalculating at Earlier Index and Study Dependencies
There are some studies like the Zig Zag and High Low For Time Period studies which recalculate themselves at an earlier index as compared to the last bar updated in the chart during normal chart updating. Studies which are based upon or dependent some way upon the studies which are calculated that an earlier than normal index, will also calculate themselves at an earlier index.
Examples of dependent studies which could take more than an insignificant amount of calculation time would be the Spreadsheet Study, or the Color Bar Based on Alert Condition study. Although even these studies are generally efficient.
Depending upon the overall study configuration (the studies being used and their dependency upon each other), there can be an increase in calculation time.
*Last modified Sunday, 04th July, 2021.