PurifyPlus performance and scalability tips

The following IBM® Rational® PurifyPlus™ tips are applicable for profiling 32-bit native Microsoft® Windows® applications and managed code applications (Java™ technology and Microsoft® .NET™ technology).

When using IBM® Rational® PurifyPlus™ with very large, enterprise-class applications, there are two types of problems that you might encounter:

  • Scalability: The program under test (PUT) uses a lot of memory by itself. Using PurifyPlus in this environment results in premature profiler runtime data buffer overflows or changes in PUT behavior from low-memory conditions.
  • Runtime performance: In some cases, PUT execution with PurifyPlus could be slowed down by a factor of 100 or more, which changes PUT behavior and becomes unacceptable for enterprise-class use.

The following tips are applicable for profiling 32-bit native Microsoft® Windows® applications and managed code applications (Java™ technology and Microsoft® .NET™ technology).

Increase the available virtual memory

All 32-bit applications have 4 GB process address space. By default, only 2 GB is available to the application. Another 2 GB is reserved for the operating system.

The easiest way to increase the amount of available virtual memory is to run the system in 3 GB mode, where the OS uses only 1 GB. This mode is available on the Windows 2003 server, Windows XP SP2, and the Windows 2000 server. To take advantage of this mode, follow these steps:

  1. Add a /3GB parameter to the boot.ini file and reboot the machine. For example: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003"/fastdetect /3GB .
  2. Use the PurifyPlus option of –large-address-aware This option enables instrumented PUT to use addresses above 2 GB, even if the original PUT is not capable of doing that.
  3. Use the PurifyPlus option of –runtime-data-size to allocate a very large runtime data buffer (up to 0x3f000000 bytes, almost 1 GB) without severely depriving the PUT of available memory. (See Figure 1.)

Sometimes, even 3 GB of available address space might not be enough, especially if the PUT is already designed to run in 3 GB mode. In this case, consider running it with PurifyPlus on a 64-bit operating system, so the PUT will have 4 GB of available address space.

Figure 1. Allocating a very large runtime data buffer
Figure 1. Screen view of where to allocate a very large runtime data buffer

Use selective instrumentation

With this mode, only the modules the the user explicitly selects are monitored. This avoids the heavy overhead of monitoring third-party and system modules. See Quantify and Coverage in PurifyPlus Help for details about how to use this feature.

Purify also supports selective instrumentation. Currently, it is released as a technology preview and is not documented in Help. There are additional steps and considerations that apply only to PurifyPlus. To enable selective instrumentation (SI), follow these steps:

  1. Add the following systemwide environment variable (see Figure 2):
    1. Select Start > Settings > Control Panel > System. Under the Advanced tab, select Environment Variables
    2. Click New under System variables.
    3. Set Variable Name to IBM_RATIONAL_PURIFY_ENABLE_SELECTIVE.
    4. Set Variable Value to 1 (one).
Figure 2. Adding the selective instrumentation system variable
3 screen captures showing steps to create a new Java interface
  1. Rebuild the target modules with the static version of the C Runtime (CRT).

PurifyPlus manipulates memory in a way that can be handled properly only by instrumented modules. For SI to function properly, you must isolate the CRT heap that the instrumented modules are using. The recommended way to achieve heap isolation is by building all modules that you plan to instrument with a static CRT. This ensures that each instrumented module has its own isolated CRT heap.

Switching to a static CRT can pose problems for modules that share CRT resources. For more information, see Microsoft's MSDN® article, "Potential Errors Passing CRT Objects Across DLL Boundaries" (see Resources). If you need to share CRT resources or you are otherwise unable to rebuild your modules with a static CRT, see the next section, which explains the dynamic CRT workaround.

To use the static version of the CRT, replace the /MD or /MDd compiler switches with /MT (release) or /MTd (debug). You need to make this change on all compile lines for the target module and on all static libraries that are linked into the target module. You can also make the change through the Microsoft® Visual Studio® IDE:

  • In Visual Studio 6:
    Select Project > Settings > C/C++ tab > Category: Code Generation > Use runtime library: Multithreaded or Debug Multithreaded. (See Figure 3.)
Figure 3. Settings for using the static CRT in Visual Studio 6
Figure 3. Screen views of settings for using the static CRT in Visual Studio 6
  • In Visual Studio .NET:
    Select Project > Properties > C/C++ folder > Code Generation > Runtime Library: Multi-threaded or Multi-threaded Debug. (See Figure 4.)
Figure 4. Settings for using the static CRT in Visual Studio .NET
Figure 4. Shows screen settings for using the static CRT in Visual Studio .NET

Make the change at the root configuration level for the target module and all static dependencies. It is not necessary to change the build settings for modules that are not instrumented. If you need to use /MT or /MTd switches with a module that links with MFC, then you also need to use the static version of the MFC libraries:

  • In Visual Studio 6:
    Select Project > Settings > General tab > Microsoft Foundation Classes: Use MFC in a Static Library. (See Figure 5.)
Figure 5. Using the MFC in a Static Library in VIsual Studio 6
Figure 5. Shows using the MFC in a Static Library in VIsual Studio 6
  • Visual Studio .NET:
    Select Project > Properties > General > Use of MFC: Use MFC in a Static Library. (See Figure 6
Figure 6. Using the MFC in a Static Library in VIsual Studio .NET
Figure 6. Shows using the MFC in a Static Library in VIsual Studio .NET
  1. Verify that you have set the recommended build options:
    1. Alse be sure to verify that the target modules are built with the standard, recommended settings for PurifyPlus. At a minimum, SI requires debug information and relocation data for the target modules.
    2. See "Recommended Settings for Visual Studio 6" or "Recommended Settings for Visual Studio .NET" in the Purify Help for more information.
  1. Selectively instrument the target modules (see Figure 7 ):
    1. Start the Purify GUI.
    2. Select Settings > Default Settings > PowerCheck > Selected Modules > Configure.
    3. Add the target modules to the list.
    4. Set each module's Instrumentation State to Permanent.
    5. Click OK to set the instrumention for the selected modules.
Figure 7. Settings to selectively instrument the target modules
Figure 7. Shows settings to instrument the target modules
  1. Run your application as usual. Purify will automatically start collecting data when an instrumented module loads.

Using the dynamic CRT workaround for selective instrumentation

It is highly recommended that you use a static CRT with SI. However, this is not always possible. Therefore, you can also isolate the heap by careful use of the dynamic debug CRT. If you use that method:

  • All instrumented modules must link with the debug version of the dynamic CRT (/MDd).
  • All uninstrumented modules must use a different CRT (/MD, /MTd, or /MT).
  • You must copy the debug CRT (msvcrtd.dll, msvcr70d.dll, or msvcr71d.dll) and its corresponding pdb to your application directory and selectively instrument the debug CRT, along with your target modules. Your application must load this copy of the CRT, not the System32 version.

How to avoid assertion failure notices

"Debug assertion failure" notices that you get during an SI run may indicate that you have not followed the CRT usage guidelines. Using SI without adhering to the CRT usage guidelines is not supported. For more information on using selective instrumentation with your application, contact IBM Rational Support.


Customize profiling for big projects

Start profiling a big project in Function mode. After you isolated candidates for performance bottlenecks, profile them in Line mode. This is most applicable to performance profiling of managed (Java™ and .NET) code. Using Function mode as default measurement level significantly reduces profiling overhead and improves runtime performance. After you have identified potential performance bottlenecks, you can profile them in Line mode to achieve the maximum level of detail. (See Figure 8.)

Figure 8. Setting Line and Function measurement level options
Figure 8. View of setting Line and Function measurement level options

Use the PurifyPlus API to gain more control

You can use PurifyPlus API to record data only for interesting areas of the program

PurifyPlus comes with a set of API functions that can be called from the PUT. They provide greater control over tracking errors and collecting performance, coverage, and memory profiling data for native-compiled and managed (Java and .NET) code. Product-specific APIs (Purify API, Quantify API, and Coverage API) are designed to work with native-compiled and Microsoft® Visual Basic® code. IBM Rational PureAPI functions provide equivalent functionality for Java and .NET code.

For very big projects, to avoid premature runtime data buffer overflows and minimize the amount of noise, you can record data only for areas of interest by calling PureAPI.

  1. Immediately after you start the PUT, click Pause recording on the Rational Quantify toolbar to avoid recording irrelevant data. (See Figure 9.)

Note: You can also do this by inserting a call to StopRecordingData API at the beginning of the main function.

Figure 9. Click Pause to avoid recording irrelevant data
Figure 9. Shows where to click Pause to avoid recording irrelevant data
  1. Then, insert calls to StartRecordingData API before interesting areas of the program, and insert matching calls to StopRecordingData API after them.

The result of these actions is that only the data about the areas that interest you will be recorded.

For more information about PureAPI and product-specific API functions, see PurifyPlus online Help.


Use prefilters to minimize noise and improve runtime performance

For Java or .NET applications, a large portion of profiling data often comes from runtime libraries. In many cases, it is just a noise, which does not help to optimize your code. Plus, collecting it increases overhead and makes the resulting dataset more difficult to analyze. The prefiltering capability of PurifyPlus can filter out this noise. You can use it from either the GUI or the command line. Prefiltering has two modes of operation: Exclusive and Selective.

  • In Exclusive mode, you can specify which classes to exclude from monitoring (see Figure 10).
Figure 10. Exclusive mode options
Figure 10. Screen capture of Exclusive mode options
  • In Selective mode, you can specify which classes to monitor. Because this stipulates what you want to include, everything else will be excluded. (See Figure 11.)
Figure 11. Selective mode options
Figure 11. Screen capture of Selective mode options

For more information about prefiltering, see Help in PurifyPlus.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=200466
ArticleTitle=PurifyPlus performance and scalability tips
publish-date=03132007