### Fast lookup table ideas

I need a really fast lookup table:

-it will accept a two digit hex number
-the first digit will locate the row of the table (1-F) and the 2nd the column (1-F)
-returns the value of that column/row.

At the moment I have something like this and it is way too slow:

 ``12345678910111213141516171819202122232425262728293031323334353637`` `````` int tolookup2 = tolookup; //find this number string inttostring; stringstream hexout; hexout << hex<< tolookup2; inttostring = hexout.str();//convert to hex if (inttostring.length()==1) //if less than 2 digits add 0 to start { inttostring.insert(0,"0"); } int column,row; if (inttostring[0] >='0' && inttostring[0]<='9') //if number 1-9 row = inttostring[0] - 48; else row = inttostring[0] - 87; //if a-f if (inttostring[1] >='0' && inttostring[1]<='9') column = inttostring[1] - 48; else column = inttostring[1] - 87; return table[row][column]; //table is the 2d array containing the table }``````

There must be a faster way than this?

Any ideas would be great (hash tables?).
Last edited on
 ``123`` ``````row = (tolookup >> 4) & 0xF; column = tolookup & 0xF; return table[row][column];``````
Last edited on
You're looking for a 2D array. The fastest "hash table" out there is just an array, and based on how you need to index it that's exactly what you need.

 ``123`` ``````std::vector myData (0xFF); //It doesn't matter if the vector is actually "2D", since every combination of //"rows" and "columns" has a different index. ``````

 ``123`` ``````int index; std::cin >> std::hex >> index; myData[index] = 42;``````
The fastest possible way to do it is a straight, 1D array as suggested.

That said, I cannot imagine what kind of requirements you are under to convert a two-digit hexadecimal value faster than a couple of arithmetic operations for each digit.

Have you really profiled your program or are you playing "human optimizer"?
Stringstream is horrendously slow.
Peter, that is about 230x faster than my code! Thank you!
 Stringstream is horrendously slow.

Let's not blame stringstream for your poor algorithmic choice.
Topic archived. No new replies allowed.