Re: EncodeDateTime performance

George McCollister wrote:
> oprofile is showing that memset (via dopr) is using about 60% of the CPU. I traced back further and noticed most of the usage was coming from EncodeDateTime.
>
> I'm not quite sure why oprofile is showing that memset is hogging so much CPU. Regardless, I found way to eliminate most of the sprintf calls that were taking place in my situation.
>
> I made some modifications to EncodeDateTime and have attached them as a patch. These changes alone reduced the query time of
the "select * from archivetbl;" from 79 seconds to just 35 seconds.

I remember I saw a similar effect some time ago, in a test case of
dumping a table with lots of timestamp columns. It was on 32-bit Linux,
which uses the glibc sprintf, instead of the one in src/port, and the
time wasn't spent in MemSet but in the glibc sprintf. However, the fix I
came up with was exactly the same: replace sprintf with functions like
that, which takes removes the overhead of parsing the format string on
every invocation.

It then occurred to me that the compiler could do the same for us, and
posted that idea on the gcc mailing list:

http://gcc.gnu.org/ml/gcc/2007-10/msg00073.html

I got busy with other stuff, and never got the chance to follow up with
that for gcc, or with a patch to PostgreSQL.

It does seem like it would be worthwhile to do something about this.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com