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
theusage 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
mostof 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
timeof 
 
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