Performance Optimization Guide

The need to optimize KLA performance may come from different execution scenarios:

• a local single user (using KLA GUI) analyzing an application that does not finish successfully or demands a very high amount of resources (in terms of memory and/or execution time)
• a continuous integration system where local analysis is part of the build process and needs a very fast performance on analysis, thus avoiding unneeded blocking waiting periods.

There are two ways to configure the KLA to optimize performance: 

• Optimize the Content and the Scope of the Analysis with Kiuwan Local Analyzer
• Optimize your Local Machine for the Kiuwan Local Analyzer

Execute a ruleset according to your needs

By default, the rules analysis steps execute all of the model's active rules for every file. 

The default model (CQM) contains approx 900 rules, of which 700 are active. This means that for every file, 700 rules will be executed on their source code.

Choose a model that suits your needs the most, activating only the rules that are important to you. 

A large set of rules will generate defects for high-priority rules as well as for low-priority ones. 

Further reading: Read more in our Guide to Model Management. 

Mute or deactivate a rule

Rules can be either muted or deactivated. 

Muting a rule means that the rule will still be executed in the background, however, the results will be hidden (e.g. in the event of many false positives)

Deactivating a rule means that the rule will not be executed at all (e.g. found defects are uninteresting or do not apply to your application). Deactivating rules speeds up the analysis process and makes it more manageable. 

Further reading: Read more in our Guide to Model Management. 

Process JSP in Java analyses

If you are analyzing Java, there’s a configuration option that has a considerable impact on analysis performance and memory needs:

• process JSP as Java servlets?

If this option is set to true (the default value), for every JSP Kiuwan will internally generate its Java servlet code and will execute the Java rules to it.

This servlet code generation consumes a considerable amount of time and memory.

The advantage of generating it is a higher precision in detecting Code Security vulnerabilities spread between JSPs and Java files (mainly XSS). 

If this is not your concern, you can set this property to false and the execution will be faster and will run with less memory needs.

Pay attention to ambiguous file extensions

• .sql matches PL_SQL, Transact and Informix,
• .c/.h matches C, C++ and Objective-C

GUI mode: KLA detects such ambiguous situations and asks the user to select the correct technology.

CLI mode: KLA will execute by default every available engine, wasting time and resources producing confusing results. To solve this, search for the supported.technologies parameter when invoking KLA in CLI mode and delete the unneeded technologies. 

Note: Import/export SQL scripts - Export/import SQL scripts are quite common in applications, and those files are usually very large. Make sure you exclude those scripts from the analysis by changing the default SQL configuration, if you want to speed up your analysis.

Duplicated code analysis

Duplicated code analysis (aka clone detection) is also quite an intensive memory and CPU-draining task.

However, it can be configured to modify its working mode, reducing time and memory requirements.

Note: If you are not interested at all in duplication code analysis, you can make Kiuwan not execute it:In KLA CLI mode, specify ignore=clones 

Kiuwan’s clone detector searches for fragments of tokens that are very similar.

The term ‘token’ refers to each of the atomic elements identified by the analyzer. There are three types of tokens:

1. Operators and reserved words (specific for each language)
2. Identifiers: variable names, function names, etc.
3. Literals: numbers and string constants used in the code.

Kiuwan also generates defects of ‘duplicated code’ according to the size of the fragments found:

You can configure the minimum tokens that Kiuwan uses to detect a clone. This is done at two levels:

• In Kiuwan’s Local Analyzer go to Advanced options, then configure the number of tokens to detect a clone. You can configure a different number of clones for each language
• In your model, configure the minimum tokens to generate a ‘Duplicated code’ defec

Depending on this configuration, Kiuwan gets different results in the clone detection. Let's see these in detail.

The most conservative way

In this case, we configure Kiuwan to look for an exact match between the different fragments:

{language}.min.tokens=20
{language}.ignore.literals=false
{language}.ignore.identifiers=false

Take this source code as an example:

Kiuwan detects duplicate code

Note: The ‘clone’ begins at the close parenthesis of line 5, but Kiuwan prints the complete line. This may be a little messy sometimes.

The detected tokens are:

Set the clone detector to be smarter

Now we are going to configure Kiuwan to ignore the numbers and string constants in our code:

{language}.min.tokens=20
{language}.ignore.literals=true
{language}.ignore.identifiers=false

As you can see in the picture above, now the fragment is bigger because the literals (‘3’ and ‘8’) are not taken into account.

The third option

As the third option, we can ignore literals and identifiers:

{language}.min.tokens=20
{language}.ignore.literals=true
{language}.ignore.identifiers=true

With this last option, the most efficient one, it was clear that the class DupCodeTestCopy is a copy-paste where the class was only renamed, so Kiuwan detects the whole class as a clone.

But this configuration is also the one most prone to false positives. For example:

Both files have a similar structure, but functionally they are very different. Ignoring literals and identifiers, Kiuwan considers both a clone.

# Starting size for heap memory (128m = 128 Megabytes)
memory.start=128m
# Maximum size for heap memory (1024m = 1 Gigabyte)
memory.max=1024m
# Stack memory, per thread (1024k = 1 Megabyte)
stack.size=2048k

If you notice the process is performing a high activity of JVM garbage collection, even without an OOM, this situation may indicate your analysis needs more memory and the performance is suffering due to GC activity. In this case, try to increase the max memory, most probably the analysis performance will be faster.

Timeout configuration

By default, every step of a local analysis is configured to a default max execution time (60 minutes) (analyzer.properties):

# Timeout to use for max execution time of each analysis step (in msecs)
timeout=3600000

If this happens, increase the default value.