[PHP-DEV] Poor date() performance (v 5.4.9) [PATCH]
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!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Poor date() performance (v 5.4.9) [PATCH]
My apologies, pasting the patch in directly:
--- php-5.4.9_orig/ext/date/php_date.c 2012-11-20 23:12:20.0 -0600
+++ php-5.4.9/ext/date/php_date.c 2012-12-01 05:38:22.136264276 -0600
@@ -948,6 +948,7 @@
timelib_time_offset *offset = NULL;
timelib_sll isoweek, isoyear;
int rfc_colon;
+ char weekYearSet = 0;
if (!format_len) {
return estrdup("");
@@ -974,7 +975,6 @@
offset = timelib_get_time_zone_info(t->sse, t->tz_info);
}
}
- timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear);
for (i = 0; i < format_len; i++) {
rfc_colon = 0;
@@ -990,8 +990,12 @@
case 'z': length = slprintf(buffer, 32, "%d", (int)
timelib_day_of_year(t->y, t->m, t->d)); break;
/* week */
- case 'W': length = slprintf(buffer, 32, "%02d", (int)
isoweek);
break; /* iso weeknr */
- case 'o': length = slprintf(buffer, 32, "%d", (int)
isoyear);
break; /* iso year */
+ case 'W':
+ if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d,
&isoweek, &isoyear); weekYearSet = 1; }
+ length = slprintf(buffer, 32, "%02d", (int)
isoweek); break; /*
iso weeknr */
+ case 'o':
+ if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d,
&isoweek, &isoyear); weekYearSet = 1; }
+ length = slprintf(buffer, 32, "%d", (int)
isoyear); break; /* iso year */
/* month */
case 'F': length = slprintf(buffer, 32, "%s",
mon_full_names[t->m
- 1]); break;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Poor date() performance (v 5.4.9) [PATCH]
--- php-5.4.9_orig/ext/date/php_date.c 2012-11-20 23:12:20.0 -0600
+++ php-5.4.9/ext/date/php_date.c 2012-12-01 05:38:22.136264276 -0600
@@ -948,6 +948,7 @@
timelib_time_offset *offset = NULL;
timelib_sll isoweek, isoyear;
int rfc_colon;
+ char weekYearSet = 0;
if (!format_len) {
return estrdup("");
@@ -974,7 +975,6 @@
offset = timelib_get_time_zone_info(t->sse, t->tz_info);
}
}
- timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear);
for (i = 0; i < format_len; i++) {
rfc_colon = 0;
@@ -990,8 +990,12 @@
case 'z': length = slprintf(buffer, 32, "%d", (int)
timelib_day_of_year(t->y, t->m, t->d)); break;
/* week */
- case 'W': length = slprintf(buffer, 32, "%02d", (int)
isoweek); break; /* iso weeknr */
- case 'o': length = slprintf(buffer, 32, "%d", (int)
isoyear); break; /* iso year */
+ case 'W':
+ if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear); weekYearSet =
1; }
+ length = slprintf(buffer, 32, "%02d", (int)
isoweek); break; /* iso weeknr */
+ case 'o':
+ if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear); weekYearSet =
1; }
+ length = slprintf(buffer, 32, "%d", (int)
isoyear); break; /* iso year */
/* month */
case 'F': length = slprintf(buffer, 32, "%s",
mon_full_names[t->m - 1]); break;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Poor date() performance (v 5.4.9) [PATCH]
Submitted here: https://bugs.php.net/bug.php?id=63666 Also note that this can probably be back-ported into other 5.x branches where this is applicable. I have only personally checked out the latest release branch at this time. Thanks! On Sat, Dec 1, 2012 at 6:06 PM, Christopher Jones wrote: > > > On 12/01/2012 10:21 AM, Paul Taulborg wrote: >> >> >> [php_date.c patch] > > > Thanks for the patch. To ensure it isn't lost, can you open a bug at > https://bugs.php.net/ and attach it? And/or submit a pull request at > https://github.com/php/php-src > > Regards, > > Chris > > -- > christopher.jo...@oracle.com > http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] date/strtotime poor performance - further digging (v 5.4.9)
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
[PHP-DEV] Re: date/strtotime poor performance - further digging (v 5.4.9) [PATCH]
I ended up digging deeper and created a patch for this, and have created a bug with the patch attached. https://bugs.php.net/bug.php?id=63699 Summary of changes: - Created a new tz_checked_valid flag on the global date structure - Created a callback method when date.timezone is modified by the ini (set) - Callback checks validity if set during runtime, and will error (with line number) accordingly. This is probably useful for some users that might no otherwise have realized they made a mistake on their ini_set() line in their code. - In guess_timezone(), if tz_checked_valid is not set, attempts to validate, errors if cannot. As previously noted from my benchmarks, over 1 million runs, it increased performance from: date: 1.751 sec strftime: 1.872 sec strtotime : 3.195 sec to: date: 1.238 sec strftime: 0.999 sec strtotime : 2.337 sec Here is a test case to show that it will not blow up on invalid timezones, and revalidates accordingly: Note: If the ini is actually set wrong, it will not error until they call a date function that makes use of the timezone, just like before. Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #63615 DateTime::modify() ignores timezone [PATCH]
I looked into this, and the modify function was not setting the
timezone information back to the parent dateobj. I have created a
patch that does this, IF the timezone information is set on the new
modified timestamp. It is attached to the bug itself, and here as
well.
This is, of course, assuming that date_modify() should actually modify
the timezone information. If this is intended functionality, then this
patch will fix it. If not, the bug should be closed as a no fix.
Thanks
--- ../php-5.4.9_orig/ext/date/php_date.c 2012-11-20 23:12:20.0
-0600
+++ ext/date/php_date.c 2012-12-05 10:27:47.586424481 -0600
@@ -2763,6 +2763,24 @@
dateobj->time->s = 0;
}
}
+
+ if(tmp_time->zone_type) {
+ dateobj->time->zone_type = tmp_time->zone_type;
+ switch (tmp_time->zone_type) {
+ case TIMELIB_ZONETYPE_ID:
+ dateobj->time->tz_info = tmp_time->tz_info;
+ break;
+ case TIMELIB_ZONETYPE_OFFSET:
+ dateobj->time->z = tmp_time->z;
+ break;
+ case TIMELIB_ZONETYPE_ABBR:
+ dateobj->time->z = tmp_time->z;
+ dateobj->time->dst = tmp_time->dst;
+ dateobj->time->tz_abbr = strdup(tmp_time->tz_abbr);
+ break;
+ }
+ }
+
timelib_time_dtor(tmp_time);
timelib_update_ts(dateobj->time, NULL);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #63615 DateTime::modify() ignores timezone [PATCH]
Can someone remove the patch from this bug for me? While it fixes the problem, it opens up some potential memory leaks, so I'd hate to see it get implemented by mistake before I get a chance to fix that as well. Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #63615 DateTime::modify() ignores timezone [PATCH]
Okay, here is the proper fixed patch, tested via various methods:
$d1 = new DateTime;
while(1) {
// no memory leak
$d1->modify("Tue, 10 Apr 2012 11:27:56 +0300");
// memory leak - now fixed with new patch
$d1->modify("Tue, 10 Apr 2012 11:27:56 CST");
// no memory leak
$d1->modify("Tue, 10 Apr 2012 11:27:56 Pacific/Chatham");
}
Attaching this second patch to the original bug report, as well as
including here.
Thanks!
--- ../php-5.4.9_orig/ext/date/php_date.c 2012-11-20 23:12:20.0
-0600
+++ ext/date/php_date.c 2012-12-06 03:19:26.597301993 -0600
@@ -2763,6 +2763,25 @@
dateobj->time->s = 0;
}
}
+
+ if(tmp_time->zone_type) {
+ dateobj->time->zone_type = tmp_time->zone_type;
+ switch (tmp_time->zone_type) {
+ case TIMELIB_ZONETYPE_ID:
+ dateobj->time->tz_info = tmp_time->tz_info;
+ break;
+ case TIMELIB_ZONETYPE_OFFSET:
+ dateobj->time->z = tmp_time->z;
+ break;
+ case TIMELIB_ZONETYPE_ABBR:
+ if(dateobj->time->tz_abbr) free(dateobj->time->tz_abbr);
+ dateobj->time->z = tmp_time->z;
+ dateobj->time->dst = tmp_time->dst;
+ dateobj->time->tz_abbr = strdup(tmp_time->tz_abbr);
+ break;
+ }
+ }
+
timelib_time_dtor(tmp_time);
timelib_update_ts(dateobj->time, NULL);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] (v 5.4.11-dev) ext/date/php_date.c cleanup
Went through and did some general code cleanup, namely removing
tabs/spaces from empty lines, or trailing spaces/tabs.
The exceptions to that are:
php_date_initialize() -- reorganized timezone setting to do it all at
once without the need for temporary variables. This should be slightly
faster, and also more readable.
date_format() -- changed the naming of the "is set" variable to comply
with PHP core coding conventions, and reorganized the switch statement
to be more readable and formatted more properly for the options of W
and o. (This was previously my patch)
Thanks
diff --git a/ext/date/php_date.c b/ext/date/php_date.c
index b588227..625788d 100644
--- a/ext/date/php_date.c
+++ b/ext/date/php_date.c
@@ -526,7 +526,7 @@ static zend_object_handlers date_object_handlers_period;
#define DATE_SET_CONTEXT \
zval *object; \
object = getThis(); \
-
+
#define DATE_FETCH_OBJECT \
php_date_obj *obj; \
DATE_SET_CONTEXT; \
@@ -688,7 +688,7 @@ PHP_RSHUTDOWN_FUNCTION(date)
* RFC2822, Section 3.3: http://www.ietf.org/rfc/rfc2822.txt
* FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
* CFWS= *([FWS] comment) (([FWS] comment) / FWS)
- *
+ *
* date-time = [ day-of-week "," ] date FWS time [CFWS]
* day-of-week = ([FWS] day-name)
* day-name= "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" /
"Sun"
@@ -710,19 +710,19 @@ PHP_RSHUTDOWN_FUNCTION(date)
* date-fullyear = 4DIGIT
* date-month = 2DIGIT ; 01-12
* date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year
- *
+ *
* time-hour = 2DIGIT ; 00-23
* time-minute = 2DIGIT ; 00-59
* time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules
- *
+ *
* time-secfrac= "." 1*DIGIT
* time-numoffset = ("+" / "-") time-hour ":" time-minute
* time-offset = "Z" / time-numoffset
- *
+ *
* partial-time= time-hour ":" time-minute ":" time-second [time-secfrac]
* full-date = date-fullyear "-" date-month "-" date-mday
* full-time = partial-time time-offset
- *
+ *
* date-time = full-date "T" full-time
*/
#define DATE_FORMAT_RFC3339 "Y-m-d\\TH:i:sP"
@@ -804,7 +804,7 @@ PHP_MSHUTDOWN_FUNCTION(date)
PHP_MINFO_FUNCTION(date)
{
const timelib_tzdb *tzdb = DATE_TIMEZONEDB;
-
+
php_info_print_table_start();
php_info_print_table_row(2, "date/time support", "enabled");
php_info_print_table_row(2, "\"Olson\" Timezone Database Version",
tzdb->version);
@@ -855,7 +855,7 @@ static char* guess_timezone(const timelib_tzdb *tzdb
TSRMLS_DC)
if (!DATEG(default_timezone)) {
/* Special case: ext/date wasn't initialized yet */
zval ztz;
-
+
if (SUCCESS ==
zend_get_configuration_directive("date.timezone", sizeof("date.timezone"),
&ztz) &&
Z_TYPE(ztz) == IS_STRING &&
Z_STRLEN(ztz) > 0 &&
@@ -936,8 +936,8 @@ char *php_date_short_day_name(timelib_sll y, timelib_sll m,
timelib_sll d)
timelib_sll day_of_week = timelib_day_of_week(y, m, d);
if (day_of_week < 0) {
return "Unknown";
- }
- return day_short_names[day_of_week];
+ }
+ return day_short_names[day_of_week];
}
/* }}} */
@@ -950,7 +950,7 @@ static char *date_format(char *format, int format_len,
timelib_time *t, int loca
timelib_time_offset *offset = NULL;
timelib_sll isoweek, isoyear;
int rfc_colon;
- int weekYearSet = 0;
+ int week_year_set = 0;
if (!format_len) {
return estrdup("");
@@ -969,7 +969,7 @@ static char *date_format(char *format, int format_len,
timelib_time *t, int loca
offset->leap_secs = 0;
offset->is_dst = 0;
offset->abbr = malloc(9); /* GMT�\0 */
- snprintf(offset->abbr, 9, "GMT%c%02d%02d",
+ snprintf(offset->abbr, 9, "GMT%c%02d%02d",
localtime ? ((offset->offset
< 0) ? '-' : '+') : '+',
localtime ?
abs(offset->offset / 3600) : 0,
localtime ?
abs((offset->offset % 3600) / 60) : 0 );
@@ -993,11 +993,17 @@ static char *date_format(char *format, int format_len,
timelib_time *t, int loca
/* week */
case 'W':
- if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear); weekYearSet =
1; }
- length = slprintf(buffer, 32, "%02d", (int)
isoweek); break; /* iso weeknr */
case 'o':
- if(!w
[PHP-DEV] Re: [PATCH] (v 5.4.11-dev) ext/date/php_date.c cleanup
Sorry for the double message, still getting used to doing patches
instead of applying changes directly. I accidentally attached an old
patch file, not the latest. The previous had a bug in
php_date_initialize() which I caught in my testing (I left the local
variable tzi, by mistake, instead of using now->tz_info), but didn't
regenerate the patch file. Caught up upon reviewing the patch itself
and realizing it was the old one. :-/
Attached is the proper patch, thanks.
diff --git a/ext/date/php_date.c b/ext/date/php_date.c
index b588227..c1c53cf 100644
--- a/ext/date/php_date.c
+++ b/ext/date/php_date.c
@@ -526,7 +526,7 @@ static zend_object_handlers date_object_handlers_period;
#define DATE_SET_CONTEXT \
zval *object; \
object = getThis(); \
-
+
#define DATE_FETCH_OBJECT \
php_date_obj *obj; \
DATE_SET_CONTEXT; \
@@ -688,7 +688,7 @@ PHP_RSHUTDOWN_FUNCTION(date)
* RFC2822, Section 3.3: http://www.ietf.org/rfc/rfc2822.txt
* FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
* CFWS= *([FWS] comment) (([FWS] comment) / FWS)
- *
+ *
* date-time = [ day-of-week "," ] date FWS time [CFWS]
* day-of-week = ([FWS] day-name)
* day-name= "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" /
"Sun"
@@ -710,19 +710,19 @@ PHP_RSHUTDOWN_FUNCTION(date)
* date-fullyear = 4DIGIT
* date-month = 2DIGIT ; 01-12
* date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year
- *
+ *
* time-hour = 2DIGIT ; 00-23
* time-minute = 2DIGIT ; 00-59
* time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules
- *
+ *
* time-secfrac= "." 1*DIGIT
* time-numoffset = ("+" / "-") time-hour ":" time-minute
* time-offset = "Z" / time-numoffset
- *
+ *
* partial-time= time-hour ":" time-minute ":" time-second [time-secfrac]
* full-date = date-fullyear "-" date-month "-" date-mday
* full-time = partial-time time-offset
- *
+ *
* date-time = full-date "T" full-time
*/
#define DATE_FORMAT_RFC3339 "Y-m-d\\TH:i:sP"
@@ -804,7 +804,7 @@ PHP_MSHUTDOWN_FUNCTION(date)
PHP_MINFO_FUNCTION(date)
{
const timelib_tzdb *tzdb = DATE_TIMEZONEDB;
-
+
php_info_print_table_start();
php_info_print_table_row(2, "date/time support", "enabled");
php_info_print_table_row(2, "\"Olson\" Timezone Database Version",
tzdb->version);
@@ -855,7 +855,7 @@ static char* guess_timezone(const timelib_tzdb *tzdb
TSRMLS_DC)
if (!DATEG(default_timezone)) {
/* Special case: ext/date wasn't initialized yet */
zval ztz;
-
+
if (SUCCESS ==
zend_get_configuration_directive("date.timezone", sizeof("date.timezone"),
&ztz) &&
Z_TYPE(ztz) == IS_STRING &&
Z_STRLEN(ztz) > 0 &&
@@ -936,8 +936,8 @@ char *php_date_short_day_name(timelib_sll y, timelib_sll m,
timelib_sll d)
timelib_sll day_of_week = timelib_day_of_week(y, m, d);
if (day_of_week < 0) {
return "Unknown";
- }
- return day_short_names[day_of_week];
+ }
+ return day_short_names[day_of_week];
}
/* }}} */
@@ -950,7 +950,7 @@ static char *date_format(char *format, int format_len,
timelib_time *t, int loca
timelib_time_offset *offset = NULL;
timelib_sll isoweek, isoyear;
int rfc_colon;
- int weekYearSet = 0;
+ int week_year_set = 0;
if (!format_len) {
return estrdup("");
@@ -969,7 +969,7 @@ static char *date_format(char *format, int format_len,
timelib_time *t, int loca
offset->leap_secs = 0;
offset->is_dst = 0;
offset->abbr = malloc(9); /* GMT�\0 */
- snprintf(offset->abbr, 9, "GMT%c%02d%02d",
+ snprintf(offset->abbr, 9, "GMT%c%02d%02d",
localtime ? ((offset->offset
< 0) ? '-' : '+') : '+',
localtime ?
abs(offset->offset / 3600) : 0,
localtime ?
abs((offset->offset % 3600) / 60) : 0 );
@@ -993,11 +993,17 @@ static char *date_format(char *format, int format_len,
timelib_time *t, int loca
/* week */
case 'W':
- if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear); weekYearSet =
1; }
- length = slprintf(buffer, 32, "%02d", (int)
isoweek); break; /* iso weeknr */
case 'o':
- if(!weekYearSet) {
timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek, &isoyear); weekYearSet =
1; }
-
[PHP-DEV] Re: Bug #63699 Poor date()/etc performance [PATCH]
Are there any updates on this? I submitted this patch a month ago that is a significant performance increase for some commonly used date/time functions: https://bugs.php.net/bug.php?id=63699 Can anyone provide feedback on this, and any possible reasons why this seems to be shelved? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get a PHP bug fixed?
I submitted a bugfix patch for this one: https://bugs.php.net/bug.php?id=63615 on 2012-12-06 and asked for feedback here, to make sure this was intended functionality. I also have not heard back, and the bug is still unassigned. It's not something that ever affected me personally, it was a random bug that I saw and fixed while in the date/time section of the core. Thanks in advance :) On Fri, Jan 4, 2013 at 11:36 AM, Ferenc Kovacs wrote: > On Fri, Jan 4, 2013 at 6:33 PM, Enumag wrote: > >> Hi, there is a bug(s) I'd like to be fixed and even a patch is available. >> But there is still no reaction at all after 2 years. What else can I do to >> get the bug(s) fixed? >> >> https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 >> https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 >> > > bringing that up here can help! :) > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Date timezone performance/cleanup [PATCH]
https://bugs.php.net/bug.php?id=63941 Per discussion with Nuno Lopes and Christopher Jones, I have created another patch to simplify guess_timezone() in ext/date/php_date.c Internals summary: removes the newly patched in int value that caches whether a timezone was previously checked or not, as well as reduces complexity by only using timezone for the stored (and checked) timezone value. default_timezone is still used locally for ini_set() calls, but is copied to timezone when checked as valid. Does give a slight performance increase due to less compiled ops. If anyone has any feedback, let me know. Thanks in advance! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting separate outputs with Date Functions
On Wed, Feb 20, 2013 at 1:54 PM, David Soria Parra wrote:
> On 2013-02-19, Stas Malyshev wrote:
>> Hi!
>>
>>> echo date_create('@1361240634')->format('Y-m-d');
>>> // output: 2013-02-19
>>>
>>> echo date('Y-m-d',1361240634);
>>> // output: 2013-02-18
>>
>> timestamp dates are created with UTC TZ, date() assumes your configured TZ.
>
> I ran into this myself and I personally consider date() assuming your
> configured TZ A bug. Timestamps are defined as UTC and the behaviour of
> DateTime is correct there, that it always assume UTC. date() should do
> the same. But then date() behaviour has been that way since ages
> and probably a lot of code out there is assuming the current TZ when
> using date().
>
Hi David,
I made a patch for a similar issue here:
https://bugs.php.net/bug.php?id=63615
I wonder if this would fix your issue as well.
I pulled it as a random bug fix, but did note that there is some
discrepancy on whether this is intended behavior or not. I'm with Stas
that we should either fix it and make it consistent, or document why
it isn't.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Don't make this more complicated than it needs to be, observe: http://news.php.net/php.internals 1) We already have a basic/simple web interface. 2) This could be extended to have the features of forum software (threading, sorting, searching, voting, filtering) 3) All email posts would go to the extended interface, and all posts made on the web interface would be emailed to internals (in the same text format it already is in). This offers the advantages of: - Able to view topics and history at a glance, instead of everyone storing the whole history set of internals (etc) in their inboxes - Inviting to new people that don't want to use a communication platform from the 1990s (and don't want the limitations of the above email setup/management) - All the old die hard email mailing list only guys still get the usual, nothing changes (except hopefully more positive activity!) + many more, as the sky is the limit with the features that could be done for the web interface. I understand this is a hugely personal and subjective thing, but both would be one and the same in the end, other than the web interface offering hugely distinct advantages that email simple cannot do.
Re: [PHP-DEV] Forum software
On Wed, Sep 11, 2013 at 10:47 AM, Lester Caine wrote: > Paul Taulborg wrote: > >> Don't make this more complicated than it needs to be, observe: >> http://news.php.net/php.internals >> >> 1) We already have a basic/simple web interface. >> 2) This could be extended to have the features of forum software >> (threading, sorting, searching, voting, filtering) >> > > Is that really still running on 2004 code? > Perfect example of if it's not broken don't fix it :) Then throw it away and only use the code from the 1990s and stick to email mailing lists only for a language that is ubiquitous for web software. Clearly it is broken, which is why this topic and Wake Up are the most active this group has seen in the last year, in only a few hours of time.
Re: [PHP-DEV] Re: Performance update involving zval containers. Why not possible?
On Fri, Sep 20, 2013 at 10:01 AM, ruben wrote:
> Pascal Chevrel wrote:
>
>> Le 20/09/2013 14:06, ruben a écrit :
>>
>>> Hi,
>>>
>>> first of all I want to say that I am just a newbie in PHP. I am
>>> switching to PHP from other languages and I am exploring how PHP manages
>>> references. To do that I am gathering information about what happens
>>> with Symbol Tables and Variables Containers when using references. You
>>> know: reference-counting, copy-on-write and all that stuff...
>>>
>>> I found out some cases where I think that some Variable Containers
>>> copies could be skipped, thus saving memory and improving performance
>>> relying in the copy-on-write principle. I wrote a PDF trying to explain
>>> what I mean. It is not written in a very techy language, because I am
>>> just new and don't know too much about the internals, but I hope you can
>>> understand it and post your comments.
>>>
>>> Probably if my "update" hasn't been done yet, is because it is not
>>> possible, but I will very glad to hear your comments and learn from you.
>>>
>>> Thank you very much.
>>>
>>>
>> Hi Ruben,
>>
>> I think you forgot to put a link to your pdf :)
>>
>> Regards,
>>
>> Pascal
>>
>
> Sorry, here it is:
> https://www.dropbox.com/s/wxdc99miw82zje9/PHP_references.pdf
Change the function to:
function & do_something(& $s) {
and it should do what you are expecting, reusing a single reference.
http://www.php.net/manual/en/language.references.return.php for more
reference.
