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:
- Add a
/3GBparameter 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.
- Use the PurifyPlus option of
–large-address-awareThis option enables instrumented PUT to use addresses above 2 GB, even if the original PUT is not capable of doing that.
- Use the PurifyPlus option of
–runtime-data-sizeto 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
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:
- Add the following systemwide environment variable (see Figure 2):
- Select Start > Settings > Control Panel > System. Under the Advanced tab, select Environment Variables
- Click New under System variables.
- Set Variable Name to
- Set Variable Value to
Figure 2. Adding the selective instrumentation system variable
- 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
/MDd compiler switches
/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
- 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
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
/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
- 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
- Verify that you have set the recommended build options:
- 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.
- See "Recommended Settings for Visual Studio 6" or "Recommended Settings for Visual Studio .NET" in the Purify Help for more information.
- Selectively instrument the target modules (see Figure 7
- Start the Purify GUI.
- Select Settings > Default Settings > PowerCheck > Selected Modules > Configure.
- Add the target modules to the list.
- Set each module's Instrumentation State to Permanent.
- Click OK to set the instrumention for the selected modules.
Figure 7. Settings to selectively instrument the target modules
- 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
- All uninstrumented modules must use a different CRT (
- You must copy the debug CRT (
msvcr71d.dll) and its corresponding
pdbto 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
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.
- 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
- 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
- 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
For more information about prefiltering, see Help in PurifyPlus.
- Stay current with developerWorks technical events and Webcasts.
- IBM Rational PurifyPlus product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational PurifyPlus.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download a free trial version of Rational PurifyPlus V7.0.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Runtime Analysis with PurifyPlus Family of Tools forum: Ask questions about Rational PurifyPlus.
- Check out developerWorks blogs and get involved in the developerWorks community.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.