Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Date: Tue, 4 Dec 2012 10:58:58 -0600
Message-ID: <CACzKMq0Wg46jZmSWsqyXnbjc0abvxPCC3zVKeQn8moCxQu7MGA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: date/strtotime poor performance - further digging (v 5.4.9)
From: njaguar@gmail.com (Paul Taulborg)

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!