php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #50652 time call optimization
Submitted: 2010-01-04 12:18 UTC Modified: 2020-10-21 10:44 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: robert_xp at gmx dot net Assigned:
Status: Suspended Package: Date/time related
PHP Version: 5.3.1 OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: robert_xp at gmx dot net
New email:
PHP Version: OS:

 

 [2010-01-04 12:18 UTC] robert_xp at gmx dot net 
Description:
------------
Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/

I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-04 12:25 UTC] derick@php.net 
We can't do this, as for longer running scripts the value as returned by time() can change (like once every second).
 [2010-01-04 15:11 UTC] robert_xp at gmx dot net 
Yes, that's right. I think this is the only point, that speaks really against this solution but most scripts should be executed in < 0.x sec and calling time(NULL) many times can be optimized this way.

A good improvement could be, applying the patch and change the SAPI handling to check against a config variable if a optimized time handling should be used - with default using the old approach.
 [2010-01-04 21:00 UTC] rasmus@php.net 
I'm not completely against this one.  At Yahoo we replaced the 
expensive gettimeofday syscalls with a fast system-wide replacement so 
it wasn't just PHP that benefitted.  They are not insignificant and 
since the bulk of scripts do run as quick web requests where it is 
perfectly fine for all time calls to get the request timestamp, and 
sometimes it even fixes edge-case bugs when they do, so the idea of 
having some sort switch to enable this optimization is not bad.  We 
would probably have to keep the default as it is though to avoid any BC 
breaks.
 [2010-11-18 23:58 UTC] jani@php.net
-Package: Feature/Change Request +Package: Date/time related -Operating System: +Operating System: *
 [2020-10-21 10:44 UTC] cmb@php.net
-Status: Analyzed +Status: Suspended
 [2020-10-21 10:44 UTC] cmb@php.net 
Apparently, there would be the need to discuss the details of this
feature request, for what this bug tracker is hardly suitable.
Therefore, please forward the request to the PHP internals mailing
list[1].  For the time being, I'm suspending this ticket.

[1] <https://www.php.net/mailing-lists.php#internals>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Oct 11 13:01:27 2024 UTC