[PHP-DEV] re2c --no-generation-date
Any objections to applying the attached patch? This would suppress date output in the generated output so that (hopefully) files generated by re2c are not changed during the build just because of the date. From 21f8149129609594a01bb08c77088effbe422aa7 Mon Sep 17 00:00:00 2001 From: Sebastian Bergmann sebast...@php.net Date: Tue, 4 Dec 2012 09:17:49 +0100 Subject: [PATCH] Invoke re2c with --no-generation-date to prevent unintentional/unnecessary changes in generated files. --- Makefile.frag | 4 ++-- Zend/Makefile.am | 4 ++-- ext/pdo/Makefile.frag | 2 +- ext/phar/Makefile.frag | 2 +- ext/standard/Makefile.frag | 4 ++-- win32/build/Makefile | 4 ++-- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Makefile.frag b/Makefile.frag index c8b3cb2..12646c2 100644 --- a/Makefile.frag +++ b/Makefile.frag @@ -7,7 +7,7 @@ $(builddir)/zend_language_scanner.lo: $(srcdir)/zend_language_parser.h $(builddir)/zend_ini_scanner.lo: $(srcdir)/zend_ini_parser.h $(srcdir)/zend_language_scanner.c: $(srcdir)/zend_language_scanner.l - @(cd $(top_srcdir); $(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt Zend/zend_language_scanner_defs.h -oZend/zend_language_scanner.c Zend/zend_language_scanner.l) + @(cd $(top_srcdir); $(RE2C) $(RE2C_FLAGS) --no-generation-date --case-inverted -cbdFt Zend/zend_language_scanner_defs.h -oZend/zend_language_scanner.c Zend/zend_language_scanner.l) $(srcdir)/zend_language_parser.h: $(srcdir)/zend_language_parser.c $(srcdir)/zend_language_parser.c: $(srcdir)/zend_language_parser.y @@ -18,6 +18,6 @@ $(srcdir)/zend_ini_parser.c: $(srcdir)/zend_ini_parser.y @$(YACC) -p ini_ -v -d $(srcdir)/zend_ini_parser.y -o $@ $(srcdir)/zend_ini_scanner.c: $(srcdir)/zend_ini_scanner.l - @(cd $(top_srcdir); $(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt Zend/zend_ini_scanner_defs.h -oZend/zend_ini_scanner.c Zend/zend_ini_scanner.l) + @(cd $(top_srcdir); $(RE2C) $(RE2C_FLAGS) --no-generation-date --case-inverted -cbdFt Zend/zend_ini_scanner_defs.h -oZend/zend_ini_scanner.c Zend/zend_ini_scanner.l) $(builddir)/zend_indent.lo $(builddir)/zend_highlight.lo $(builddir)/zend_compile.lo: $(srcdir)/zend_language_parser.h diff --git a/Zend/Makefile.am b/Zend/Makefile.am index 5ec4590..d6ca339 100644 --- a/Zend/Makefile.am +++ b/Zend/Makefile.am @@ -31,7 +31,7 @@ zend_ini_scanner.lo: zend_ini_parser.h # Language parser/scanner rules zend_language_scanner.c: $(srcdir)/zend_language_scanner.l - $(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt $(srcdir)/zend_language_scanner_defs.h -o$@ $(srcdir)/zend_language_scanner.l + $(RE2C) $(RE2C_FLAGS) --no-generation-date --case-inverted -cbdFt $(srcdir)/zend_language_scanner_defs.h -o$@ $(srcdir)/zend_language_scanner.l zend_language_parser.h: zend_language_parser.c zend_language_parser.c: $(srcdir)/zend_language_parser.y @@ -43,7 +43,7 @@ zend_ini_parser.c: $(srcdir)/zend_ini_parser.y $(YACC) -p ini_ -v -d $(srcdir)/zend_ini_parser.y -o zend_ini_parser.c zend_ini_scanner.c: $(srcdir)/zend_ini_scanner.l - $(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt $(srcdir)/zend_ini_scanner_defs.h -o$@ $(srcdir)/zend_ini_scanner.l + $(RE2C) $(RE2C_FLAGS) --no-generation-date --case-inverted -cbdFt $(srcdir)/zend_ini_scanner_defs.h -o$@ $(srcdir)/zend_ini_scanner.l zend_ini_parser.h: zend_ini_parser.c diff --git a/ext/pdo/Makefile.frag b/ext/pdo/Makefile.frag index 98f5c5f..5ba5f80 100644 --- a/ext/pdo/Makefile.frag +++ b/ext/pdo/Makefile.frag @@ -6,7 +6,7 @@ PDO_HEADER_FILES= \ $(srcdir)/pdo_sql_parser.c: $(srcdir)/pdo_sql_parser.re - (cd $(top_srcdir); $(RE2C) -o ext/pdo/pdo_sql_parser.c ext/pdo/pdo_sql_parser.re) + (cd $(top_srcdir); $(RE2C) --no-generation-date -o ext/pdo/pdo_sql_parser.c ext/pdo/pdo_sql_parser.re) install-pdo-headers: @echo Installing PDO headers: $(INSTALL_ROOT)$(phpincludedir)/ext/pdo/ diff --git a/ext/phar/Makefile.frag b/ext/phar/Makefile.frag index b1c820f..e2b016d 100644 --- a/ext/phar/Makefile.frag +++ b/ext/phar/Makefile.frag @@ -1,5 +1,5 @@ $(srcdir)/phar_path_check.c: $(srcdir)/phar_path_check.re - @(cd $(top_srcdir); $(RE2C) -b -o ext/phar/phar_path_check.c ext/phar/phar_path_check.re) + @(cd $(top_srcdir); $(RE2C) --no-generation-date -b -o ext/phar/phar_path_check.c ext/phar/phar_path_check.re) pharcmd: $(builddir)/phar.php $(builddir)/phar.phar diff --git a/ext/standard/Makefile.frag b/ext/standard/Makefile.frag index 4e94962..8b6e3e2 100644 --- a/ext/standard/Makefile.frag +++ b/ext/standard/Makefile.frag @@ -1,9 +1,9 @@ $(srcdir)/var_unserializer.c: $(srcdir)/var_unserializer.re - @(cd $(top_srcdir); $(RE2C) -b -o ext/standard/var_unserializer.c ext/standard/var_unserializer.re) + @(cd $(top_srcdir); $(RE2C) --no-generation-date -b -o ext/standard/var_unserializer.c ext/standard/var_unserializer.re) $(srcdir)/url_scanner_ex.c:
[PHP-DEV] Things move slowly in the real world ;)
Not sure if the date is significant, but just received notification that 11 will drop support for PHP4 and PHP5.2 from April 1, 2013 - yes PHP4 is still available as their default! The move is to PHP5.4, but the interesting thing is that they are calling it PHP6 simply to isolate it from PHP5.2 http://faq.1and1.co.uk/scripting/php/5.html I keep being told that 'It's just a number', but this is an example of why rolling yet another significantly different version of PHP5 causes problems in user land. The frameworks are jumping to the next major release to support 5.4 over 5.2 and providers like 11 need an easy way to manage what they PROVIDE to users. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Things move slowly in the real world ;)
What a great way to confuse people. On Tue, Dec 4, 2012 at 4:04 AM, Lester Caine les...@lsces.co.uk wrote: Not sure if the date is significant, but just received notification that 11 will drop support for PHP4 and PHP5.2 from April 1, 2013 - yes PHP4 is still available as their default! The move is to PHP5.4, but the interesting thing is that they are calling it PHP6 simply to isolate it from PHP5.2 http://faq.1and1.co.uk/**scripting/php/5.htmlhttp://faq.1and1.co.uk/scripting/php/5.html I keep being told that 'It's just a number', but this is an example of why rolling yet another significantly different version of PHP5 causes problems in user land. The frameworks are jumping to the next major release to support 5.4 over 5.2 and providers like 11 need an easy way to manage what they PROVIDE to users. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Things move slowly in the real world ;)
On 4 December 2012 09:04, Lester Caine les...@lsces.co.uk wrote: April 1, 2013 The date is somewhat suspicious ;)
Re: [PHP-DEV] Things move slowly in the real world ;)
On Tue, 2012-12-04 at 09:04 +, Lester Caine wrote: The move is to PHP5.4, but the interesting thing is that they are calling it PHP6 simply to isolate it from PHP5.2 http://faq.1and1.co.uk/scripting/php/5.html well, the actual reason is that they offered the old PHP 6 before as experimental and then simply swapped that for 5.3 back in the days and since then have been lazy. I keep being told that 'It's just a number', but this is an example of why rolling yet another significantly different version of PHP5 causes problems in user land. The frameworks are jumping to the next major release to support 5.4 over 5.2 and providers like 11 need an easy way to manage what they PROVIDE to users. So how does a string matter? - We might also call it PHP 98 or PHP 2000 or PHP XP or whatever. What's the difference? Only that peopleare more afraid. Having difference between minor versions isn't new i.e. PHP 4.4 broke many things due to the fixes in the reference handling there. Compared to that the breakage between 5.2 and 5.3 or 5.3 and 5.4 is small. It is especially small when comparing it with PHP 3 to PHP 4 (complete reimplementation, changed behavior of include/require etc.) and PHP 4 to PHP 5 (redone OO model, changing objects from being value types to reference types) johannes -- 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
Re: [PHP-DEV] Things move slowly in the real world ;)
Lester, are you seriously suggesting we coddle providers who either [a] Willfully misrepresent the PHP versioning system, showing they are utterly tuned out of the PHP support community? or [b] Play unfunny practical jokes on their users and/or troll this very list? If anything, their behavior is a call for some official censure, IMO. I have sympathy for their users, but the only cure for that is to find a responsible provider. If providers just told the truth about the whys of what they support, instead of lying about stability, security, or other boldface reasons, users would be better served. One such reason: We should have done this long ago, but held off longer than necessary for budget reasons. Now, we're behind the curve and can't get new customers who are version-aware. You'll enjoy the performance rewards of re/building for the new version. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Things move slowly in the real world ;)
Sanford Whiteman wrote: Lester, are you seriously suggesting we coddle providers who either [a] Willfully misrepresent the PHP versioning system, showing they are utterly tuned out of the PHP support community? Well they are only one of the ISP's who have been posting PHP6 as their next supported version, and been waiting for it to appear. These are the people who have to support naive users who are NOT in a position to re-write code just to make it work with later versions of PHP5, and needing to still run PHP5.2 in parallel with PHP5.4 is not the easiest thing to do on shared hosting? But I was posting it so that people will not be surprised when 'php6' starts appearing in bug reports where users have changed and now need help to fix the problems. I stopped using 11's versions of PHP a number of years ago, switching to my own machines with them simply so I could control versions but I can quite understand why they have not switched away from PHP5.2 and they are now providing PHP5.4 as a selectable option, but which HAS to co-exist with their existing working infrastructure! How else could this situation be handled? I'm lead to believe that the date was chosen simply because they do consider the situation a bit of a joke ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Things move slowly in the real world ;)
I'm lead to believe that the date was chosen simply because they do consider the situation a bit of a joke ... Speaking as a current and long-time customer of 1and1 hosting, I do believe that their business situation is a bit of a joke. I know this is not a list to talk about various hosting providers, but I'll just say I won't be doing business with them for much longer. This is just another point of feedback I can give to them when I do change service. Incorrectly reporting your service offering regardless of what type of business you run is a really poor decision. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Things move slowly in the real world ;)
On Tue, Dec 4, 2012 at 3:57 PM, Levi Morrison morrison.l...@gmail.comwrote: I'm lead to believe that the date was chosen simply because they do consider the situation a bit of a joke ... Speaking as a current and long-time customer of 1and1 hosting, I do believe that their business situation is a bit of a joke. I know this is not a list to talk about various hosting providers, but I'll just say I won't be doing business with them for much longer. This is just another point of feedback I can give to them when I do change service. Incorrectly reporting your service offering regardless of what type of business you run is a really poor decision. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think we should do what Microsoft does with Windows and just pull version names out of a hat. We could call 5.5 PHP XP and 5.6 PHP Vista. A separate branch with slightly more features could be called PHP Vista Ultimate and hosting providers could use a custom-branded one called PHP Vista Ultimate for Workgroups. We could release 6.0 right now with tons of bugs and call it PHP Derp, then a few months later put out 6.1 as PHP 7. The goal should be to confuse the hell out of our users as much as possible. Step 1: Confuse users. Step 3: Profit. Seriously, though, 1and1 is a joke. That's not exactly breaking news. If it really bugs us that much, we could always put up a statement on the website rebuking their misrepresentation of our version numbering and leak it to a few tech blogs. Otherwise, it's probably best to just laugh it off and move on. --Kris
Re: [PHP-DEV] Things move slowly in the real world ;)
On 5 December 2012 08:26, Kris Craig kris.cr...@gmail.com wrote: Seriously, though, 1and1 is a joke. That's not exactly breaking news. If it really bugs us that much, we could always put up a statement on the website rebuking their misrepresentation of our version numbering and leak it to a few tech blogs. Otherwise, it's probably best to just laugh it off and move on. I had a rant about it on Twitter yesterday, and will probably use it as the punchline for a joke in a conference talk next month. That's probably about the level of disgust, er... recognition it deserves. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re2c --no-generation-date
Hi! Any objections to applying the attached patch? This would suppress date output in the generated output so that (hopefully) files generated by re2c are not changed during the build just because of the date. I think it is a great idea. If we ever need a date for checked in files, we have it on git commit, date in the text is not useful anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re2c --no-generation-date
On 12/05/2012 06:06 AM, Stas Malyshev wrote: Any objections to applying the attached patch? This would suppress date output in the generated output so that (hopefully) files generated by re2c are not changed during the build just because of the date. I think it is a great idea. If we ever need a date for checked in files, we have it on git commit, date in the text is not useful anyway. Okay. But does the patch look okay? Is it sufficient? How can I force a rebuild of all files generated through re2c to remove the date from the files? To which branches should the patch be applied? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
