I presume the lookup table code comes from the hex2string/string2hex
code.
I added it there because it significantly speed up operations with
long strings, while keeping compatibility (your shift solution
would probably be faster, though).
The reason it works well there is because the strings in
Yes, but wasn't sscanf the fast code?
sscanf is fast. Taking the code from sscanf and putting it in a stand
alone function is not as fast. This is what confuses me.
One of our developers just did a hex string to int conversion with
array_sscanf(x, %x)[0]. Since we have int2hex, string2hex and
hex2string I thought it would be symmetric to add a hex2int function
as well. However doing it with
/*! @decl int hex2int(string hex)
*! @appears String.hex2int
was about twice as slow as the array_sscanf approach. Is that because
some special sscanf handling?
Probably due to the use of a lookup table.
BTW: Why don't you use wide_string_to_svalue_inumber() or STRTOL_PCHARP()?
It's as slow with the switch solution from the sscanf code.
Yes, but wasn't sscanf the fast code?
Anyway, if you want to try something exotic, you can try:
int low_hex2int(int c)
{
int q = c 0x40;
return (c + (q3) + (q6)) 0xf;
}
