Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66067
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACzKMq0Wg46jZmSWsqyXnbjc0abvxPCC3zVKeQn8moCxQu7MGA@mail.gmail.com>
References: <CACzKMq0Wg46jZmSWsqyXnbjc0abvxPCC3zVKeQn8moCxQu7MGA@mail.gmail.com>
Date: Wed, 20 Feb 2013 19:37:41 +0100
Message-ID: <CAH-PCH663gyHTVo_Fm-QECwnDf3zE+QAtTo=HjEmMdm32i6Ncw@mail.gmail.com>
To: Paul Taulborg <njaguar@gmail.com>, Derick Rethans <derick@derickrethans.nl>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93408c5d730a004d62c402d
Subject: Re: [PHP-DEV] date/strtotime poor performance - further digging (v 5.4.9)
From: tyra3l@gmail.com (Ferenc Kovacs)

--14dae93408c5d730a004d62c402d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 4, 2012 at 5:58 PM, Paul Taulborg <njaguar@gmail.com> wrote:

> 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
>
>
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!

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--14dae93408c5d730a004d62c402d--