So, I've been going through the internals of date() and related,
trying to isolate where some poor performance is, to try and find ways
to optimize it. In doing so, I came across this:
On line 863 of ext/date/php_date.c is this code:
} else if (*DATEG(default_timezone) &&
timelib_timezone_id_is_valid(DATEG(default_timezone), tzdb)) {
I noticed it's checking every time that the timezone is "still" valid.
Commenting this out results in a tremendous speed increase. From my
tests before, I saw 3.3 seconds for strtotime, and 1.75s for date.
After commenting out the timelib_timezone_id_is_valid check above,
speed increased to 2.3s and 1.2s respectively! (Tests are run 1
million times each)
It immediately jumped out at me, because on a few lines prior is
initializes DATEG(default_timezone) and checks to make sure it's valid
there. Additionally, in PHP_FUNCTION(date_default_timezone_set) it
also checks to ensure it is a valid timezone.
Having only glanced at what ini_set() does internally, I can presume
this check is there to prevent a bad value being set via that command?
However, I'm not certain it directly writes the value to
DATEG(default_timezone), so it may not be relevant at all. If it does,
some better cursory bounds checking in ini_set() might save a lot of
redundant bounds checking during runtime calls. It would also make
more sense to error them out on the ini_set() line rather than on a
date() call that was the result of an improperly configured value.
Rather than spending time digging into that when it may not be
applicable I figured I'd ask here if anyone is more familiar with the
inner-workings of ini_set and other globals that can give me some
insight into this? Seems like an easy optimization to make, if I'm not
missing something else.
Thanks!
So, I've been going through the internals of
date()and related,
trying to isolate where some poor performance is, to try and find ways
to optimize it. In doing so, I came across this:On line 863 of ext/date/php_date.c is this code:
} else if (*DATEG(default_timezone) &&
timelib_timezone_id_is_valid(DATEG(default_timezone), tzdb)) {I noticed it's checking every time that the timezone is "still" valid.
Commenting this out results in a tremendous speed increase. From my
tests before, I saw 3.3 seconds for strtotime, and 1.75s for date.
After commenting out the timelib_timezone_id_is_valid check above,
speed increased to 2.3s and 1.2s respectively! (Tests are run 1
million times each)It immediately jumped out at me, because on a few lines prior is
initializes DATEG(default_timezone) and checks to make sure it's valid
there. Additionally, in PHP_FUNCTION(date_default_timezone_set) it
also checks to ensure it is a valid timezone.Having only glanced at what
ini_set()does internally, I can presume
this check is there to prevent a bad value being set via that command?
However, I'm not certain it directly writes the value to
DATEG(default_timezone), so it may not be relevant at all. If it does,
some better cursory bounds checking inini_set()might save a lot of
redundant bounds checking during runtime calls. It would also make
more sense to error them out on theini_set()line rather than on a
date()call that was the result of an improperly configured value.Rather than spending time digging into that when it may not be
applicable I figured I'd ask here if anyone is more familiar with the
inner-workings of ini_set and other globals that can give me some
insight into this? Seems like an easy optimization to make, if I'm not
missing something else.Thanks!
--
Hi,
Derick, could you please spare some to look into this (and maybe to look
into the couple of patches sent to the list from Paul)?
Thanks!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu