From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Performance glitch in GetCurrentAbsoluteTime() |
Date: | 1999-11-04 15:35:17 |
Message-ID: | 3821A7B5.EB0460FF@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(back online after a week of downtime)
> In utils/adt/nabstime.c, the function GetCurrentAbsoluteTime() is called
> during each StartTransaction in order to save the transaction's start
> time. It shows up unreasonably high in my profile (> 1% of runtime):
> 0.62 10.22 100001/100001 StartTransaction [65]
> [91] 1.4 0.62 10.22 100001 GetCurrentAbsoluteTime [91]
> 0.92 8.30 100001/100001 localtime [105]
> 0.88 0.00 100001/100004 time [305]
> 0.12 0.00 100001/104713 strcpy [479]
> Now the interesting thing about this is that the essential part of the
> function is just the time() call, AFAICS, and that's quite cheap. More
> than 90% of the runtime is being spent in the "if (!HasCTZSet)" branch.
> I see no reason for that code to be run during every single transaction.
> It sets the following variables:
> CTimeZone
> CDayLight
> CTZName
> CDayLight is not used *anywhere* except for debug printouts, and could
> go away completely.
OK, let's kill it.
> CTZName is not used if USE_POSIX_TIME is defined,
> which is true on most platforms.
OK, it should be #ifndef'd
> CTimeZone is not quite as useless, but
> there are only a couple places where it's used when USE_POSIX_TIME is
> true, and they don't look like critical-path stuff to me.
> We could almost say that these variables need only be set once per
> backend startup, but I suppose that would do the wrong thing in a
> backend that's left running over a daylight-savings transition.
Right. If we were only supporting WinDoze, then we wouldn't need to
worry. But my linux box stays up forever, so daylight savings time
transitions are important ;)
> What I'm inclined to do is arrange for these variables to be calculated
> only on-demand, at most once per transaction. It'd be even nicer to
> get rid of them entirely, but I don't think I understand the time code
> well enough to venture that.
At most once per transaction is what I was hoping the behavior already
is. Anyway, if we can take the time() result and *later* figure out
the other values, then we could:
1) clear a flag when time() is called
2) use a wrapper around a stripped GetCurrentAbsoluteTime() for
date/time support
3) if the flag in (1) is clear, then evaluate the other parameters
- Thomas
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 1999-11-04 15:43:51 | Re: [HACKERS] pgaccess 0.98 |
Previous Message | Andrzej Mazurkiewicz | 1999-11-04 15:10:54 | Inheritance of functions |