Re: date/strtotime poor performance - further digging (v 5.4.9)
On Tue, Dec 4, 2012 at 5:58 PM, Paul Taulborg <[email protected]> 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!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Thread (2 messages)