Running the testHash program

The testHash program shows how to use Quantify to improve performance.

The hashtable package

Suppose you are part of a team developing a compiler and you are assigned the task of developing a symbol table that associates various programming language and user tokens with different parsing and lexical information. You implement a hashtable package and a unit test program to ensure that it works. Before you incorporate the hashtable package into the compiler, you use Quantify to find any performance bottlenecks.

Note:

You can find the source code for the testHash program and the unit test program in <Quantifyhome>/example_quantify.

The unit test program reads a file of tokens and exercises the hashtable package against the test dataset. The hashtable package itself supports inserting, fetching, and deleting hashtable entries. Each hashtable is a fixed size array (called the "backbone") containing pointers to a chain of hashtable entries.

The chain of hashtable entries from each array element is called a "bucket."

Given a string token such as "serve", the hashtable package computes a 32-bit hash key, in this case 0x79c9c5a, based on the characters in the string. The hashtable package uses the hashkey modulo the size of the hashtable backbone to determine what bucket to search and then scans the entries in the bucket looking for the entry with the same string.

Collecting baseline performance data

Build the testHash program using the makefile for your system. For example, on SunOS type:

% make -f makefile.sun testHash.pure

Run the testHash program with a test dataset:

% testHash.pure 500 test_words

Begin the analysis of the testHash program by reviewing Quantify's program summary:

Note:

Testing the hashtable package involves only the compute-bound operations of inserting and removing items from a data structure. The only system calls you might expect during hashtable testing are the result of printing the test results via printf and requesting memory for the hashtable data structures via malloc. This means that you are interested in the major functions contributing to the Time in your code category and not in Time in system calls category.

You can now examine the performance data that Quantify has collected, and look for unexpected behavior. Click to continue.