When you profile an application, the console view does not appear in the Profiling and Logging perspective by default.
To open the console view in the Profiling and Logging perspective, select Window->Show View->Console.
To get stdout to appear in the Console click Window->Preferences->Run/Debug->Console and select Show when program writes to standard out.
The performance of the profiling tools is directly related to the amount of data being collected, and the rate at which this data is transferred to the workbench. As the amount of data being collected increases, a user will experience decreased performance both in terms of the time it takes to do analysis, and in terms of the memory available for performing different tasks. There are several ways that a user can enhance the profiling performance.
- A good place to start is to collect the minimum amount of data you think is sufficient to profile a given piece of functionality. This can be accomplished by setting up a more efficient Filter in the Profiling launch configuration. In the Run->Profile dialog, select the Profiling tab. Select a profiling set, followed by the Edit button, followed by Next > and you'll be at the Filter dialog. Use a filter to just include areas of interest. You can always change the filter to include different or more data on a later run.
- If you don't want to profile the startup code, try unchecking the "Automatically start monitoring on application launched" checkbox on the Profiling - Limits tab of the Run->Profile dialog. That should help reduce the time it takes to launch the program being analyzed, and also eliminate start-up code from being profiled. Note that to start profiling, you need to click the "start monitoring" toolbar button in the Profiling Monitor after the workspace comes up.
- You can try redirecting the output to a file. This will use less memory in RAD. You can import the file into RAD at a later time when it is being used only for looking at this profiling file so it has more memory free for this task. This is done via the Run->Profile dialog, select the Profiling Tab, Destination subtab and select the "send profiling data to a file" checkbox before profiling. Later use the File->Import dialog, and select the Profiling File type. Note that you can not view the data while profiling if this option is selected. You must Import first, then you can view it. There is an opportunity to further reduce the amount of memory by only importing a piece of the profiling file in the Import dialog. Maybe importing different pieces and examining them independently will help.
- Profiling can result in a lot of memory overhead, so it might help to increase the virtual memory being used by RAD. To start RAD with 512MB of virtual memory (and 1GB maximum), please add the following line to your rationalsdp.ini file: VMArgs=-Xms512m -Xmx1024m
- If the problem is during data collection on the target system, you might try increasing the size of the buffers it uses to send data to RAD. Add the following line to the serviceconfig.xml and restart the agent. (This will increase the buffer size to 256MB). In very CPU intensive apps, increasing the data channel size further also helps: <Agent configuration="default" name="Java Profiling Agent" dataChannelSize="256M" type="profiler"/>
Probekit source files with non-ASCII characters in their names will not be processed correctly. Use only ASCII characters in Probekit source file names.
Do not use non-ASCII characters in the patterns for Probekit "Target" specifications. Probes which contain non-ASCII characters in Target patterns will not be processed correctly.
During profiling, all double byte characters show up as ???? in the console view.
Return to the main readme file