Yes, 99% of the time I know the text will match one
of the case statements.  I tried a conversion of the
string to a number but I lost time in the conversion
before actually comparing to the hashed value.  

I either needed to come up with a faster hash so I
could do a numeric comparison or forego the case
statements by using a jump table, compensating for
the computation time.

After quite a bit of experimentation I figured that
if I (or anyone else) had an idea for a jump table
I might be able to beat the clock at a cost of code
ugliness and loss of flexibility.

W.

-----Original Message-----
From: Joe Lewis Wilkins [mailto:PepeToo@...]
Sent: Tuesday, April 23, 2002 7:26 PM
To: futurebasic@...
Subject: Re: [FB] Fast lookups and jumps


Hi Wave,

Since you "appear" to know what the strings are, why not
substitute integers for them, or even convert them to ascii
numbers before you use the SELECT/CASE structure. Seems
to me that they could become 1,2,3,4, etc.

Or am I being too naive?

Joe Wilkins

"Edwards, Waverly" wrote:

> I have the need for speed.  Does anyone have a
> better idea for a jump table to replace a SELECT/CASE
> structure?
>
> What I would like to do is to jump to a certain section
> based on the contents of a string.  The string will be one
> to four characters in length, all capitals.
>
> What I am doing now is easy and flexible but
> I think there may be a faster, less flexible way to do
> the same thing.  Ultimately, I want to see if I can gain
> enough speed to warrant some ugly inflexible code.
>
> This is what I do now.
>
> SELECT myString$
> CASE "BD"
> // do this ...
> CASE "LI"
> // do this ...
> CASE "SIMM"
> // do this ...
> CASE "XY"
> // do this ...
> CASE "D"
> // do this ...
> ....
> ....
> ....
> // THERE ARE ABOUT 40 CASE STATEMENTS
> // ORDERED BY FREQUENCY FOR SPEED.
> ....
> ....
> END SELECT
>
> I get good speed now but I what I would like to do is something like
> using an array as a lookup table
>
> hashVal = FN hashString(myString)
>  // hash value is the index into array
>
> jumpAddr = myAddrLookup(hashVal)
> // array will need to be large and mostly
> // empty to support a direct relationship
> // of hash value to index
>
> goto jumpAddr
>
> "BD"
> // do this ...
> EXIT FN
> "LI"
> // do this ...
> EXIT FN
> "SIMM"
> // do this ...
> EXIT FN
>
> The problem here is that it would take longer to compute the hash value
> than it would to go through the select statements.  Unfortunately I cant
> do this
>
> hashVal = [@myString +1]
>
> because the string length is variably one to four characters
>
> I cant do this
>
> select myString[0]  // string length
> case 1
>    hashVal = myString[1]
> case 2
>    hashVal = myString.1%
> case 3
>    // cant do three at all
> case 4
>   hashVal = myString.1&
> end select
>
> because I use up time just testing the string length before I get to the
> table lookup.
>
> I'm willing to sacrifice memory, inflexible and ugly code in order to
> test the idea of getting nearly instantaneous jumps but none of the
> ideas I have are fast.
>
> Any ideas?
>
> W.
>
> --
> To unsubscribe, send ANY message to
<futurebasic-unsubscribe@...>


--
To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>