SlickEdit Core was designed with speed in mind. Most operations perform nearly instantaneously. However, the size and location of your codebase can affect SlickEdit Core performance along with various settings within SlickEdit Core. This guide will help you to make sure that you get the best performance possible.
In some cases, Symbol Coloring can cause delays while typing. If you are experiencing performance problems while typing, please turn off that feature to see if the problem is fixed. For more information, see Symbol Coloring.
Virus checkers also might be a cause for bad performance. Many do real-time checking each time a file is read. When trying to diagnose the cause of a performance problem, please turn off any such checking. Some virus checkers give you the option of exempting specific file types from these checks. If so, you can achieve better performance by exempting SlickEdit Core tag files (.vtg). You may also wish to exempt your source files from these checks.
Whenever possible, make sure that your source code files and configuration files are stored locally. SlickEdit Core is subject to normal file latency. When files are stored remotely they take longer to access.
Storing your source files remotely will increase the amount of time it takes to open and save files. Additionally, it will increase the amount of time it takes to tag your files. Tagging is the process of building a symbol database, which is used for many advanced operations in SlickEdit Core. On a fast, reliable network you may find that storing your source files remotely does little to harm performance. On a slow network, these operations will likely take unacceptably long to complete.
Your SlickEdit Core Configuration files should also be stored locally. This is where SlickEdit Core stores a great deal of information about your options and the state of SlickEdit Core. Having these files located remotely will introduce latency at unpredictable times.
By default, SlickEdit Core stores your config files in \\My
Documents\My SlickEdit Core Config on Windows and in $HOME/.secore
on Linux. These are typically on a local drive. You can specify a different location for
your config using the -vsconfig option when Eclipse is launched:
eclipse -vsconfig /dev/coreconfig
If necessary, use this option to specify a new location for your config files that is on a local drive.
Along with making sure that your tag files are stored locally, you should make sure that SlickEdit Core has enough memory to hold all of your tag files in memory. When it doesn't, it has to page sections of the tagging database in and out of the cache.
To increase the size of your tag file cache, select Window → SlickEdit Preferences → Editing → Context Tagging and change the value for Tag file cache size (KB). Try to make it large enough (within reason) so that we can get your entire workspace tag file and extension specific tag files into memory. To determine that size, open Tools → Tag Files. This lists all of the tag files in SlickEdit Core. Not all of them are used at any one time, though. You may also want to adjust the value for Tag file cache maximum (KB). This setting controls the maximum amount of memory that can be dedicated to the tag file cache depending on the amount of memory available on your machine at the time that SlickEdit Core starts. If you have a machine with lots of memory available, setting this maximum to a large value is the simplest way to get good tag file performance without having to worry about adding up the total sizes of your tag files as described below.
For a given workspace, you need to add the size of your project tag files, listed at the top of the tree, to the size of the extension-specific tag files used in that workspace. If you are only using a single language, then it will just be the one extension-specific tag file. If you are using a mixture of languages, you will need to add the tag file for each language. If you have tagged multiple tool chains in a given language, like GNU C/C++ and Microsoft Visual Studio, you need only factor in the one used by that workspace. The Tag Files dialog will tell you the location of the tag files. Use the operating system to determine the size of the files. Add them together, and use that value for the tag file cache size.
The tag file cache size is a global value that is used for all workspaces, so you should set this value for your largest workspace. If that workspace is atypical or infrequently used, set it based on the tag file sizes used by a more typical workspace.
It is possible that you could hit a threshold where increasing the cache size reduces performance. This is likely to be the case if the tag file cache size exceeds the amount of free memory available on your system. So, once you've set this value check your operating system and make sure it isn't being forced to do a lot of paging. If it is, you should decrease the tag file cache size. Like most performance tuning, this could be an iterative process until you find a value that provides the best speed for your codebase and system.
After you've checked the items above, the next optimizations to try are the various control settings for Context Tagging. SlickEdit Core's Context Tagging system provides many of the advanced features that make using SlickEdit Core so great. Context Tagging creates a database of all the symbols in your code and where they are located. This is used to provide rapid navigation from a symbol to its definition, for all kinds of completions, and for rapid symbol searches. All of that information is great, but it does you no good if you have to wait too long to get it.
As mentioned above, Symbol Coloring can cause performance problems while it attempts to identify and resolve symbols. If you are having a performance issue while typing, the first thing to do is to shut off Symbol Coloring. For more information, see Symbol Coloring.
To configure Context Tagging, open Window → SlickEdit Preferences → Editing → Context Tagging. This screen contains a number of parameters you can use to control the performance of Context Tagging.
If you are experiencing sporadic pauses in SlickEdit Core, the first thing to check is that Background tagging of other files is off. It's generally fine to leave Background tagging of open files on. We recommend that you turn that off only after you've applied all other tuning approaches. Likewise, you should leave Tag file on save enabled. This ensures that the tag database is always current by tagging a file when it is saved.
The context tagging engine is single threaded with SlickEdit Core, and background tagging has been known to introduce random periods of unresponsiveness. Generally, you don't need to tag other files in the background. Once you've tagged your workspace, you only need to tag files that are being changed, and SlickEdit Core does this automatically if you leave the other two values on.
The exception to this is if you fetch updated files from a source code repository. Then, other developers may have changed files or added new ones. SlickEdit Core won't know about those changes until you retag the workspace. For normal size projects, SlickEdit Core can tag the workspace in a few minutes. On extremely large projects, this can take over an hour. Your strategy for how and when to tag depends on the size of your codebase.
For a normal codebase, you can select Tools → Retag Workspace from the Eclipse main menu. You will have to wait while SlickEdit Core retags your workspace. Retagging is generally faster since it only has to look at new or modified files.
For extremely large codebases, you may want to script this process. You could set up a nightly process that fetches all new and updated files from source control, adds the new files to appropriate projects, and then runs the tagging engine on them.
These tuning options for Context Tagging set maximum values for specific tagging operations. You can change these values when a specific operation is found to be too slow. For example, if you type in a function call, like
foo();
After typing the open parenthesis, SlickEdit Core will look for a list of local variables that match the parameters in foo. The value, Maximum candidates for list parameters determines the upper limit in that search. By default it is set to 200. Once that number is reached, it will stop looking for matches. If you find that SlickEdit Core is taking too long in this situation, you can decrease that number to, say, 100. You have to weigh the tradeoff between completeness and responsiveness.
We won't go into each of the values in that list. When you select an item in the Options dialog, help is provided that will guide your decision on whether to change that value.
You can easily degrade the performance of SlickEdit Core by changing the Context Tagging defaults. You should compare your changes to the performance using a default configuration. To create a default configuration, use the -vsconfig option on the command line:
eclipse -vsconfig config
This will launch Eclipse, putting the configuration in a "config" directory below your Eclipse install directory. Be sure to use a new location or delete that directory before launching Eclipse in this manner, or it will use the config that was already in place.
The Context Tagging options also contain a group for References. If you are experiencing performance issues with reference lookup (when using Ctrl +/ or push-ref), then you may want to change some of the values in this group. Turning on Build workspace tag file with references makes reference look-ups faster, but it makes creating tag files take longer. For normal sized codebases the slow-down is negligible, so we often turn this on.
If you have a large codebase, you may want to turn on Find references incrementally (faster). When set to True, reference queries are faster because SlickEdit Core does not open each candidate file to eliminate invalid references. So, you get your answer more quickly, but it may not be fully accurate.
SlickEdit Core includes a profiler to measure the amount of time spent in different functions. This tool can be very helpful to track down performance problems. To run the profiler, do the following:
Start the profiler from the SlickEdit Core command line by typing the following: profile on. Then press Enter.
Perform the operations to be measured. Try to include only the steps necessary to produce the problem.
Stop the profiler. From the command line, type the following: profile save "<filename>", where <filename> is the name of the file to save to. For example, you could type: profile save "profile.txt".
You can then send the file into Product Support to be analyzed.