Chapter 6. Optimizing MTR performance
MTR performance depends on a number of factors, including hardware configuration, the number and types of files in the application, the size and number of applications to be evaluated, and whether the application contains source or compiled code. For example, a file that is larger than 10 MB may need a lot of time to process.
In general, MTR spends about 40% of the time decompiling classes, 40% of the time executing rules, and the remainder of the time processing other tasks and generating reports. This section describes what you can do to improve the performance of MTR.
6.1. Deploying and running the application
Try these suggestions first before upgrading hardware.
- If possible, run MTR against the source code instead of the archives. This eliminates the need to decompile additional JARs and archives.
-
Specify a comma-separated list of the packages to be evaluated by MTR using the
--packagesargument on the<MTR_HOME>/bin/mtr-clicommand line. If you omit this argument, MTR will decompile everything, which has a big impact on performance. -
Specify the
--excludeTagsargument where possible to exclude them from processing. - Avoid decompiling and analyzing any unnecessary packages and files, such as proprietary packages or included dependencies.
- Increase your ulimit when analyzing large applications. See this Red Hat Knowledgebase article for instructions on how to do this for Red Hat Enterprise Linux.
- If you have access to a server that has better resources than your laptop or desktop machine, you may want to consider running MTR on that server.
6.2. Upgrading hardware
If the application and command-line suggestions above do not improve performance, you may need to upgrade your hardware.
- If you have access to a server that has better resources than your laptop/desktop, then you may want to consider running MTR on that server.
- Very large applications that require decompilation have large memory requirements. 8 GB RAM is recommended. This allows 3 - 4 GB RAM for use by the JVM.
- An upgrade from a single or dual-core to a quad-core CPU processor provides better performance.
- Disk space and fragmentation can impact performance. A fast disk, especially a solid-state drive (SSD), with greater than 4 GB of defragmented disk space should improve performance.
6.3. Configuring MTR to exclude packages and files
6.3.1. Excluding packages
You can exclude packages during decompilation and analysis to increase performance. References to these packages remain in the application’s source code but excluding them avoids the decompilation and analysis of proprietary classes.
Any packages that match the defined value are excluded. For example, you can use com.acme to exclude both com.acme.example and com.acme.roadrunner.
You can exclude packages by either of the following methods:
-
Using the
--excludePackagesargument. -
Specifying the packages in a file contained within one of the ignored locations. Each package should be included on a separate line, and the file must end in
.package-ignore.txt. For example, see<MTR_HOME>/ignore/proprietary.package-ignore.txt.
6.3.2. Excluding files
MTR can exclude specific files, such as included libraries or dependencies, during scanning and report generation. Excluded files are defined in a file with the .mtr-ignore.txt or .windup-ignore.txt extension within one of the ignored locations.
These files contain a regex string detailing the name to exclude, with one file listed per line. For example, you can exclude the library ant.jar and any Java source files beginning with Example with a file containing the following:
.*ant.jar .*Example.*\.java
6.3.3. Searching locations for exclusion
MTR searches the following locations:
-
~/.mtr/ignore/ -
~/.windup/ignore/ -
<MTR_HOME>/ignore/ -
Any files and folders specified by the
--userIgnorePathargument
Each of these files must conform to the rules specified for excluding packages or files, depending on the type of content to be excluded.
