Hi Jakub,
On Tue, 14 Jun 2011, Jakub Jelinek wrote:
On Tue, Jun 14, 2011 at 03:13:00PM +0300, Dimitrios Apostolou wrote:
parsing overhead and the hex conversion (implemented suboptimally in
Can you back that up? glibc conversion to hex representation is fairly
heavily optimized, see _itoa_word in stdio-common/_itoa.h. In fact, I'd
say it is much better than your implementation. The overhead
you may see almost certainly comes from the fact that printf family
have to handle lots of different stuff, including narrow/wide output,
optional groupping, localized digits and all kinds of other things.
It's true that I saw but didn't really understand glibc's _itoa(), and
just assumed it was slower since it works for all base, not only base
16 which is special. Nevertheless my measurements showed puthexl()
faster, and the genericity of the function is certainly an important
factor.
If _itoa() indeed has a better algorithm I could use it.
glibc) I changed the hottest callers with fwrite()/fputs() and
implemented a puthexl() function for hex conversion:
static void puthexl (unsigned long value, FILE *f)
{
static char hex_repr[16]= {'0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
static char buf[2 + 2*sizeof(value)]= "0x";
int i;
int j= 2;
for (i = 8*sizeof(value)-4; i>=0; i-= 4)
{
char c= (value >> i) & 0xf;
if (c!=0 || j>2)
{
buf[j]= hex_repr[(int)c];
Why not just "0123456789abcdef"[c] instead
Code just looked more beautiful, that's all. :-)
(and make c an int, instead of char).
done
Furthermore, consider instead of filling from the beginning filling from the
end.
My first version (out of 5 others) was doing that. I think there was no
actual performance difference, and filling from start helped skipping
leading zeroes and appending right after "0x".
buf shouldn't be static.
buf initialisation time I avoid that way is almost negligible, so I could
change it if necessary. But what is the problem with it being static?
Hardcoding CHAR_BIT to 8 is not portable.
Changed, didn't have a clue about that issue! I'll be delighted to learn
which platform has CHAR_BIT != 8 :-)
Thanks for your comments,
Dimitris
