We are trying to optimize a search routine for keys in fixed length rows
in an unordered array.  As the number of rows in the array grows, a
serial search becomes relatively inefficient, so we looked for another
technique.  We tried a SEARCH STRING (SRST) against a one byte hash of
the key to see if it could give us better performance.  The relative
positive of the matching byte in the SRST array was used to determine
the location of the key in the original array; if the keys match, the
row is found; if they don't match, we redrive the SRST.  At about 50
rows, SRST is more efficient than a serial search so it justifies
maintaining the hash array.
 On the average, we assume the SRST would have to be redriven about
(n/256)/2 times, where n is the number of rows in the array.  This would
not be a big factor for several thousand rows, but as the number of rows
went into the tens of thousands, we tried Search String Unicode
(SRSTU).  It appears to be identical to SRST, except it compares 2-byte
values (at 2-byte boundaries). So we created a 2-byte hash and, using
the same technique based on relative position, tested for performance
improvements compared to SRST when the number of rows exceeded 10000. 
We thought that the reduction in the number of redrives due to
non-matching keys (on average,  (n/65536)/2) would more than offset the
hash array doubling in size.

Our preliminary results show SRSTU about taking about 50-60% more time
for 15000 and 25000 rows.  That came as a surprise to us.  We will do
more testing.

Is there a possibility we are encountering a hardware vs. microcode
implementation of the instuctions?  Has anyone else tested the
performance of these instructions?

Regards, Gary

Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.

Reply via email to