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!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
