PHP 5.1 time() caching

php.internals

Ilia A.

21 years ago
As of PHP 5.1, the request start time is stored by PHP inside the sapi structure. This data is populated by the information offered by the SAPI (Apache sapis populate it) otherwise time(0) is used to get the same data. This means that PHP has a "free" unix timestamp that tells information about the request start time, which does not require a syscall. . Since a lot of script end up having to fetch request start time, this can be used to save on a timing call (This information only has second precision, no microseconds). The question is what would be the best way to provide this information within the script. The two alternatives are: adding a new function to get this info or storing this data inside $_SERVER. What do you think? Ilia

George Schlossnagle

21 years ago
On Oct 22, 2004, at 4:43 PM, Ilia Alshanetsky wrote:
> > The question is what would be the best way to provide this information > within the script. The two alternatives are: adding a new function to > get this info or storing this data inside $_SERVER. > > What do you think?
$_SERVER['request_time'] George

dharana

21 years ago
Ilia Alshanetsky wrote:
> As of PHP 5.1, the request start time is stored by PHP inside the sapi > structure. This data is populated by the information offered by the SAPI > (Apache sapis populate it) otherwise time(0) is used to get the same data. > > This means that PHP has a "free" unix timestamp that tells information > about the request start time, which does not require a syscall. > > . Since a lot of script end up having to fetch request start time, this > can be used to save on a timing call > (This information only has second precision, no microseconds).
I would think the reason for fetching request start time is to profile execution time (the first line you would see in my scripts is always $time_start = microtime()) or maybe it's just me, of course.
> > The question is what would be the best way to provide this information > within the script. The two alternatives are: adding a new function to > get this info or storing this data inside $_SERVER.
I'm for $_SERVER, it makes most sense for me.
> > What do you think? > > Ilia >
-- Juan Alonso http://gamersmafia.com | http://laflecha.net

Derick Rethans

21 years ago
On Fri, 22 Oct 2004, dharana wrote:
> Ilia Alshanetsky wrote: > > > . Since a lot of script end up having to fetch request start time, this > > can be used to save on a timing call > > (This information only has second precision, no microseconds). > > I would think the reason for fetching request start time is to profile > execution time (the first line you would see in my scripts is always > $time_start = microtime()) or maybe it's just me, of course.
For that the granularity is not good enough though.
> > The question is what would be the best way to provide this information > > within the script. The two alternatives are: adding a new function to > > get this info or storing this data inside $_SERVER.
$_SERVER Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Ilia A.

21 years ago
Derick Rethans wrote:
> For that the granularity is not good enough though.
Ideally we'd have gettimeofday() cached, but looking @ the code it is called on by lcg code and then only on MINIT. So we'd need an "extra" syscall to provide this, I am not sure this is a good idea. Ilia P.S. I didn't indicate in my earlier e-mail, I'd prefer $_SERVER as well.

George Schlossnagle

21 years ago
On Oct 22, 2004, at 5:05 PM, Ilia Alshanetsky wrote:
> Derick Rethans wrote: >> For that the granularity is not good enough though. > > Ideally we'd have gettimeofday() cached, but looking @ the code it is > called on by lcg code and then only on MINIT. So we'd need an "extra" > syscall to provide this, I am not sure this is a good idea.
I think this is available from Apache2, though not via the SAPI interface. george

Rasmus Lerdorf

21 years ago
On Fri, 22 Oct 2004, Ilia Alshanetsky wrote:
> Derick Rethans wrote: > > For that the granularity is not good enough though. > > Ideally we'd have gettimeofday() cached, but looking @ the code it is > called on by lcg code and then only on MINIT. So we'd need an "extra" > syscall to provide this, I am not sure this is a good idea. > > Ilia > > P.S. I didn't indicate in my earlier e-mail, I'd prefer $_SERVER as well.
Sticking it in $_SERVER is ok, but then you also have to hack up getenv() to recognize it and return it when asked. People interested in using this are likely people looking to avoid doing the extra syscall and these are the same people who are unlikely to populate $_SERVER at all in their configs. -Rasmus

Andi Gutmans

21 years ago
At 10:57 PM 10/22/2004 +0200, dharana wrote:
>Ilia Alshanetsky wrote: > >>As of PHP 5.1, the request start time is stored by PHP inside the sapi >>structure. This data is populated by the information offered by the SAPI >>(Apache sapis populate it) otherwise time(0) is used to get the same data. >>This means that PHP has a "free" unix timestamp that tells information >>about the request start time, which does not require a syscall. >>. Since a lot of script end up having to fetch request start time, this >>can be used to save on a timing call >>(This information only has second precision, no microseconds). > >I would think the reason for fetching request start time is to profile >execution time (the first line you would see in my scripts is always >$time_start = microtime()) or maybe it's just me, of course.
I think using current time for timestamps in DBs and so on can be very useful. I think Ilia had in mind wider use and not specifically for profiling where the performance of the initial call to time() wouldn't have any significance.
>>The question is what would be the best way to provide this information >>within the script. The two alternatives are: adding a new function to get >>this info or storing this data inside $_SERVER. > >I'm for $_SERVER, it makes most sense for me.
$_SERVER[] is fine. The downside that it's an extra hash_update() on each requests even if you don't use the time (as opposed to an internal function). But in real life this would not be noticeable. Andi