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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
