I see this as twofold.
1. Added overhead when timezone is not set -> I don't think we should
really do anything in here. It's a simple matter of adding
date_default_timezone_set("xxx/yyy") to your application. After adding
this call PHP will use that value as first in guess_timezone().
However we could put something about it to README.Debian.
2. We call stat() everytime timelib_timezone_id_is_valid() is called.
That is adds some slowdown, but I don't really see a way how to fix
that unless you readahead all timezones, which will make PHP even more
slower (mainly at startup, but that happens basically every time with
non-threaded model). But I guess we could improve the performance
little bit anyway - using snprintfs are somewhat suboptimal and some
string related functions could be improved as well. I'll do that.
Ondrej
On Wed, Mar 17, 2010 at 21:17, Filipus Klutiero <[email protected]> wrote:
> Sean, let's do that. I'll recap what I wrote in my 3 last mails.
>
> Hi all,
> at the end of February, PHP 5.3 came to me, with an expected number of
> issues. One issue that annoyed me was that a warning is now triggered if a
> time-related function is used without having set the timezone in 3 approved
> ways: the TZ environment variable, the date.timezone PHP directive or calling
> date_default_timezone_set(). Thankfully, Sean Finney made Debian's PHP quiet
> this warning - so PHP now relies on the system timezone (PHP was already able
> to use that as a last recourse, but considered it unreliable, for an obscure
> reason).
>
> But I saw something worrying related to that when attending Rasmus Lerdorf's
> Confoo talk on PHP Performance. The slides are available at
> http://talks.php.net/show/confoo10/
> Slides 16 to 20 are relevant. Slide 20 shows that with HipHop PHP, running an
> application relying on the system timezone causes the application to run 25%
> slower (before using date_default_timezone_set, 20% of the time is spent in
> HPHP::TimeZone::Current).
>
> I don't know for sure that baseline PHP is affected as badly, but it seems
> so. I seem to remember the issue is that each determination of the timezone
> causes a syscall - not sure again. It would be nice if somebody could check
> this...
> The application in question is called Twit, and I don't know what it is
> except it was written by Rasmus:
> http://www.ora600.be/news/liveblogging-confoo-not-just-php-performance-rasmus-lerdorf
> But many applications use time extensively, so I have no trouble believing
> this case is not an exception.
>
> If this problem is found to be genuine, I have no great solution and I know
> very little about timezone handling but I think caching the timezone for a
> minute or so should be OK - the timezone should change rarely, it probably
> never changes on most Debian installs. We should also be able to look at
> other programs if needed - what happens to Python applications like Trac, for
> example? Even GUI applications use time a lot.
>
> Le mars 17, 2010 02:56:30 AM, Sean Finney a écrit :
>> hi filipus,
>>
>> how about you bring this up on pkg-php for discussion?
>>
>> sean
>>
>> On Tue, Mar 16, 2010 at 09:51:27PM -0400, Filipus Klutiero wrote:
>> > Hi Sean and others,
>> > I'm back from Confoo 2010 and was able to get up early enough to see the
>> > last 15 minutes of Rasmus Lerdorf's talk on PHP performance. He was
>> > comparing HipHop PHP's performance with PHP's and had an initially slower
>> > result with HipHop. He profiled the HipHop version and after a few
>> > changes, it was still significantly slower than the PHP version. He found
>> > that a date or time function was taking about 15-20% of the execution time
>> > due to system calls querying the timezone. A simple
>> > date_default_timezone_set made the HipHop version take the lead.
>> >
>> > Now, I don't know what was the script and whether it used time/date
>> > functions a lot, but it looked like running without date_timezone, TZ and
>> > without calling date_default_timezone_set could have a significant
>> > performance hit if PHP doesn't cache the timezone. Caching the timezone
>> > for a minute or so would seem reasonable if it's not already done. I
>> > suppose the timezone is never changed on most Debian installs.
>> >
>> > I leave it to your discretion to determine whether this deserves
>> > investigation. Unfortunately, the slides aren't available, I can only
>> > suggest you ask Rasmus if you want more context.
>> >
>> > Thanks for the quick treatment of this bug,
>> > Filipus
>> >
>> > Le mars 13, 2010 06:51:14 PM, Debian Bug Tracking System a écrit :
>> > > This is an automatic notification regarding your Bug report
>> > > which was filed against the php5 package:
>> > >
>> > > #571762: [php5] please get rid of "Warning: date() [function.date]: It
>> > > is not safe to rely on the system's timezone settings."
>> > >
>> > > It has been closed by Raphael Geissert <[email protected]>.
>> > >
>> > > Their explanation is attached below along with your original report.
>> > > If this explanation is unsatisfactory and you have not received a
>> > > better one in a separate message then please contact Raphael Geissert
>> > > <[email protected]> by
>> > > replying to this email.
>
> _______________________________________________
> pkg-php-maint mailing list
> [email protected]
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
>
--
Ondřej Surý <[email protected]>
http://blog.rfc1925.org/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
