RE: Bsearch for closest match

<snip>
With 1000 elements, You're looking at the difference between 
offset/compare 1000 times vs offset/compare 10 times.  It's 100 times 
faster.  How long do those extra 990 times take?  That depends on the 
speed of your computer, the amount of memory, the size of the data
you're 
comparing, etc, etc.   Plus, how many times do you do it?
</snip>
I generally store the number of used elements in an integer field & use
For loop until I reach the end of the data.  It may not be elegant but
it works for most cases... 


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, August 22, 2006 3:45 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Bsearch for closest match

Jon, may i ask a generic question here?  In the search of a typical
array, under 1000 elements, done repeatedly, are there reasons to look
for major performance improvements?  Are there performance

improvements

that are useful?

With all due respect, this is like taking a bite of a sandwich, then 
saying "Jon, do I like the way my sandwich tastes?"

Run your program.  Does it run fast enough?  If so, you're done.  If
not, 
look for ways to make it faster.

I have always thought that these lookups were pretty darn fast anyway,
so that chasing improvements was like standing on a stepladder to get
closer to the moon?

With 1000 elements, You're looking at the difference between 
offset/compare 1000 times vs offset/compare 10 times.  It's 100 times 
faster.  How long do those extra 990 times take?  That depends on the 
speed of your computer, the amount of memory, the size of the data
you're 
comparing, etc, etc.   Plus, how many times do you do it?

Whether or not it's fast enough is a matter of opinion, based on the
needs 
of the project.