URL: http://www.pure.com.
If you have any questions or comments about The PurePulse, send email to pulse@pure.com.
For more information on any of the topics listed below, send email to info@pure.com for North America, info@europe.pure.com for Europe and info@japan.pure.com for the Pacific Rim, or call 1-800-353-7873 in the U.S. or (408)720-1600 for outside the U.S.
Both Qualtrak and Pure Software share the same vision: to dramatically improve software quality everywhere. While Qualtrak has historically focused on products for QA engineering, Pure Software has focused on product for developers.
To read more about our expanded product offering see the New Products Section below.
PureTestExpert---a commercial test management system. PureTestExpert addresses all aspects of test development, test execution, and test maintenance and includes a test execution engine that compiles, executes, and cleans up after testing. Using its internal SQL database, PureTestExpert is capable of managing a single test or the thousands of tests required in large development projects.
The new Quantify workshops teach users how to use Quantify's detailed execution information on the most time-consuming functions. As companies become more concerned about building performance into their applications (rather than rushing through performance tweaking before release time), they turn to Quantify. To ensure that development engineers get the most from Quantify we are now offering a "Lunch on Quantify" training program. Be sure to ask about it when you order Quantify!
We welcome and encourage your comments so we may continually improve technical support.
For international seminar information send e-mail to:
"Managing Testing and Automating QA"
(Mike Manley, vice-president and general manager of Pure Software
will host this series of workshops for QA managers and engineers.
Mike Manley has over 15 years experience managing QA teams and was
the founder of Qualtrak Corporation, which was recently purchased
by Pure Software.)
Pure Software is speaking at DevCon in Weisbaden Germany! A technical team member from Pure Software will be speaking about the "Quality Challenge of Programming in C and C++" May 9th at Software DevCon '95 in Weisbaden, Germany.
Pure Software will be exhibiting at HP World in Ikebukuro, Japan May 31 thru June 2. We'll be showing our products and their integration with the Softbench products from Hewlett Packard. In addition, we will be demonstrating our soon-to-be-released Japanese product versions. For more information please contact info@japan.pure.com.
By default, coverage data for various executions of each program are accumulated into the files app1.pcv, app2.pcv, etc.... If app1 and app2 share a common code base then you may want to direct the results into a common pcv file using the '-counts-file' option. To do this simply:
% setenv PURECOVOPTIONS -counts-file=/app.pcv
In the case that you wish to change your personal defaults you
can copy that file and include it in your .Xdefaults file or
just modify your .Xdefaults file to override the
To customize these display aspects under HPUX's vuewm, you can also add resources by following the procedures outlined by HP in their user's guide documentation on HP VUE. The actual procedure depends on the type of session you expect to run.
It is handy to change the colors of the messages in the Purify Viewer to reflect the message class of the error. For instance, you may want ABW, BRK, FMW, and FUM to show up as red because they are all corrupting errors. To do this, specify the following in your .Xdefaults file:
Purify*Color*enhanceStrings: "ABW", "BRK", "FMW", "FUM"
Purify*Color*ABW.enhanceForeground: white
Purify*Color*ABW.enhanceBackground: red
Purify*Color*BRK.enhanceForeground: white
Purify*Color*BRK.enhanceBackground: red
Purify*Color*FMW.enhanceForeground: white
Purify*Color*FMW.enhanceBackground: red
Purify*Color*FUM.enhanceForeground: white
Purify*Color*FUM.enhanceBackground: red
Let's say when the Purify Viewer comes up you always pulldown
the View menu to enable displaying the program control buttons
on the bottom of the Viewer. You can change the behavior such
that they come up automatically when the Viewer comes up. To
do so simply add the following line to your .Xdefaults file:
Purify*viewProgramControls.selected: trueYou can modify the default settings for the PureCov Viewer display using the same technique. For instance, the default sort criteria for the PureCov Viewer is number of unused lines. If you would like the default sorting criteria to be alphabetical instead simply add the following line to your .Xdefaults file:
PureCoverage*sortCriterion: alpha
It's easy to customize the Quantify viewer using the X resources listed in your .qvrc file. Quantify writes this file in your home directory when you exit the Quantify viewer for the first time. Edit the X resources listed in this file to change the startup behavior of Quantify viewer the next time it is run. The Quantify viewer automatically reads this file on startup so you do not have to use xrdb or interact with vuewm under HPUX to change your Quantify settings.
For example, to automatically create the Function List window on startup and have it display to top 20 functions only with increased precision, change the following lines in your .qvrc file:
Quantify*wFunctionList.createWindow: true
Quantify*wFunctionList.restrictFunctions: top20
Quantify*wFunctionList.precision: dd.ddddd
The first export data file often corresponds to data from a baseline run. The second file corresponds to the data from a changed run. Here's an example from a program where we improved the performance of a hash table by re-writing the algorithm to call the "strcmp" routine less often (which resulted in a 25% performance improvement.)
Differences between:
program ./test/hash/testHash.pure (pid 23171) collected on
sparcstation_lx(50 MHz) by Quantify version 2.0 and
program ./test/hash/improved_testHash.pure (pid 22877)
collected on sparcstation_lx (50 MHz) by Quantify version 2.0.
Function name Calls Cycles % change
! strcmp -40822 -1198546 94.53% faster
! putHash 0 -33222 7.13% faster
! getHash 0 -26876 8.10% faster
! remHash 0 -7356 5.82% faster
! _malloc_unlocke 0 -3000 6.59% faster
! sbrk 0 -1620 87.85% faster
! cleanfree 0 -810 1.39% faster
! ___errno 0 -540 81.82% faster
! testPutHas 0 -540 1.54% faster
! fillTestTable 0 -270 0.95% faster
! _doprnt 0 -270 0.07% faster
! realfree 0 -270 0.61% faster
! fgets 0 -270 0.65% faster
! testHashTable 0 -270 64.29% faster
! printf 0 -270 69.23% faster
! _exithandle 0 -270 85.99% faster
! memcpy 0 5 0.01% slower
! strlen 0 35 0.03% slower
! eucscol 0 192 0.12% slower
! hashIndex 0 10000 1.46% slower
20 differences; -1264168 cycles (-0.025 secs at 50 MHz) 24.98%
faster overall (ignoring system calls).
Each line of the report lists a function whose time differs
between runs. Each line contains a character indicating the
type of difference, followed by the function name, and the
change in the number of times called and the change in the
function time recorded. The possible function differences are:
Symbol Meaning
"-" Called in the baseline run only
"!" Called in bother runs; timing changed
"+" Called in the changed run only
For functions whose number of calls or function times have
changed, qxdiff prints these differences and reports the
percentage change relative to the baseline data for that
function. Finally, qxdiff summarizes the totaL number of
differences and reports the percentage change relative to
the baseline data and the changed run. This gives you the
information you need to verify how much improvement your
changes made.
To run this script during the nightly build, set the environment variable QUANTIFYOPTIONS to:
'-windows=no -run-at-exit="qxchange %v %x -i"'The -windows=no option setting specifies that qv should not be run interactively during the automated run. The -run-at-exit option setting specifies that the qxchange script should run whenever the program saves a dataset and that comparisons should ignore system call times.
By default, the output from qxchange is written to stdout. To email the comparison to yourself, you could set QUANTIFYOPTIONS to:
'-windows=no -run-at-exit="qxchange %v %x -i | mail $USER"'By making application performance part of your regular regression testing, you can be proactive rather than reactive in your testing. When someone checks in new code that slows down performance you will be able to spot the problem immediately.
![[More Information?]](/file/16967/CDware_Sep-Dec_1995.bin/.products/Pure/moreinfo.gif)