On 2015-09-03 16:28:40 +1200, David Rowley wrote: > > Wouldn't it be better to just normalize fsec to an integer in that case? > > Afaics that's the only remaining reason for the alternative path? > > > > A special case would need to exist somewhere, unless we just modified > timestamp2tm() to multiply fsec by 1 million when HAVE_INT64_TIMESTAMP is > not defined, but that changes the function signature.
Sure, but that's a one line #ifdef? > > We could alternatively handle this by special-casing INT_MIN, probably > > resulting in a bit less duplicated code. > > > > Those special cases seem to do some weird stuff to the performance > characteristics of those functions. I find my method to handle negative > numbers to produce much faster code. That's a bit odd. > I experimented with finding the fastest way to convert an int to a string > at the weekend, I did happen to be testing with int64's but likely int32 > will be the same. > > This is the time taken to convert 30 into "30" 2 billion times. > > The closest implementation I'm using in the patch is pg_int64tostr() one. > The pg_int64tostr_memcpy() only performs better with bigger numbers / > longer strings. > > david@ubuntu:~/C$ gcc5.2 tostring.c -o tostring -O2 > david@ubuntu:~/C$ ./tostring > pg_int64tostr_memcpy in 13.653252 seconds > pg_int64tostr in 2.042616 seconds > pg_int64tostr_new in 2.056688 seconds > pg_lltoa in 13.604653 seconds > > david@ubuntu:~/C$ clang tostring.c -o tostring_clang -O2 > david@ubuntu:~/C$ ./tostring_clang > pg_int64tostr_memcpy in 0.000004 seconds > pg_int64tostr in 2.063335 seconds > pg_int64tostr_new in 2.102068 seconds > pg_lltoa in 3.424630 seconds Are you sure this isn't an optimization artifact where the actual work is optimized away? Doing 2 billion conversions in 2s kinda implies that the string conversion is done in ~4 cycles. That seems unrealistically fast, even for a pipelined cpu. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
