Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64128
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACzKMq0PzYgh2vUx1mgcQRhCvAr-EiiwArrUr-0-8CJC7cON1w@mail.gmail.com>
References: <CACzKMq0PzYgh2vUx1mgcQRhCvAr-EiiwArrUr-0-8CJC7cON1w@mail.gmail.com>
Date: Sat, 1 Dec 2012 16:14:34 -0200
Message-ID: <CA+5g0S+m2X6Qs9TfTLNYc6EYS7brymV1vHJ3aoiS5U3xdN9puQ@mail.gmail.com>
To: Paul Taulborg <njaguar@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b343b044b67b604cfce7ea8
Subject: Re: [PHP-DEV] Poor date() performance (v 5.4.9) [PATCH]
From: felipensp@gmail.com (Felipe Pena)

--047d7b343b044b67b604cfce7ea8
Content-Type: text/plain; charset=UTF-8

Hi,

2012/12/1 Paul Taulborg <njaguar@gmail.com>

> I am migrating from 4.4.9 to some new servers I built out, and wrote a
> benchmark suite that is testing many individual aspects of PHP so I
> could see what sort of performance benefits I might see not only from
> the new server, but moving off my custom forked 4.4.9 branch. Here's a
> snippet of some of the comparisons: (sorry for the poor formatting) --
> each test is run using 1 million loops.
>
> 4.4.9 on old machine vs 5.4.9 on new machine:
> for                     : 0.213 sec     for                     : 0.019 sec
> while                   : 0.145 sec     while                   : 0.014 sec
> if else                 : 0.449 sec     if else                 : 0.069 sec
> switch                  : 0.547 sec     switch                  : 0.087 sec
> Ternary                 : 0.418 sec     Ternary                 : 0.066 sec
> str_replace             : 1.043 sec     str_replace             : 0.421 sec
> preg_replace            : 3.627 sec     preg_replace            : 1.678 sec
> preg_match              : 1.250 sec     preg_match              : 0.509 sec
>
> As you can see, the new machine is considerably faster, and there are
> no major issues with wanting to switch... until I get to the date
> functions I make frequent use of:
> date                    : 1.856 sec     date                    : 2.111 sec
> strtotime               : 2.963 sec     strtotime               : 3.133 sec
>
> and just to test (though I don't currently use it):
> strftime                : 2.679 sec     strftime                : 1.764 sec
>
> The former two actually are slower on the new box and newer version of
> php, when everything else is 2 to 200x faster.
>
> Relevant code to the functions: (tested with and without the $now
> parameter -- which makes no perceptible difference)
> date('F j, Y, g:i a', $now);
> strftime('%B %e, %Y, %l:%M %P', $now);
>
> This type of formatting is pretty common. I started digging into the
> source code, and found an obvious place where there was a performance
> issue:
> timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear);
> is being called every time, even though it's only used in two rather
> obscure cases, and ones that are probably very uncommon in actual
> practice. So, to test, I created a "is set" type variable, and moved
> the function call into each case, with a condition checking if it was
> already populated, if not, call the function to populate isoweek and
> isoyear, then resume as before. (Patch will be attached as a file)
>
> I then recompiled and reran my benchmark and here is the result:
> date: 1.763 sec
> Which is a performance increase of nearly 20%.
>
> My patch was thrown together rather quickly to just do a quick test,
> so it may warrant some tweaking before being applied to any branches.
> I plan to continue digging, as I feel that I should be able to
> continue to improve the performance of these functions further. The
> rest will be a little less obvious, is there is much more cross
> functionality issues to contend with to ensure nothing is broken.
>
> Side note- I attempted the same concept with not setting the timezone
> information if those flags were not used in the switch (which they
> aren't in anything I use), but it didn't appear to have any noticeable
> performance increase. My next step is to start tracing through actual
> execution and see if I can't find any other obvious issues. My initial
> thoughts are that it may be faster to try and cache some of this (for
> fcgi purposes), or even have a compile time option to allow a build to
> use old 4.4.9 functionality that uses localtime_r() and actually
> trusts that the server has the right information set.
>
> Thanks in advance for looking at this with me!
>
>
As far I remember, the patch must be in a .txt extension to be sent to the
list.

Thanks.

-- 
Regards,
Felipe Pena

--047d7b343b044b67b604cfce7ea8--