Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
I know, I've just replied with an example to the "Such a performance regression sounds like an appropriate "punishment" to me for deploying bad code ;-)" statement. btw: http://www.tyrael.hu/2011/06/26/performance-of-error-handling-in-php/ http://www.tyrael.hu/2011/10/09/error-suppression-improvements-with-php-5-4/ On Mon, Oct 17, 2011 at 2:49 PM, Ilia Alshanetsky wrote: > Unless you are deleting thousands of files in a tight loop, the > overhead involved won't make any difference for your application. > > In general your application is throwing many errors, even "benign" > E_STRICT or E_NOTICE you are already incurring a performance hit. > > On Mon, Oct 17, 2011 at 3:49 AM, Ferenc Kovacs wrote: > > On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev >wrote: > > > >> Hi! > >> > >> > >> On 10/16/11 5:54 PM, Sebastian Bergmann wrote: > >> > >>> Such a performance regression sounds like an appropriate "punishment" > to > >>> me for deploying bad code ;-) > >>> > >> > >> By bad code you mean not obsessively checking for stuff that is of no > >> importance to them as programmers and is only required because language > >> implementers decided to go B&D on their users? ;) > >> > >> I personally hate to see all these > isset($foo['bar'])?$foo['bar']**:null. > >> I think it's bad we make people do that. > >> > >> > > and there are cases when you can't avoid triggering errors (like trying > to > > delete delete a while which can be deleted concurrently) so your only > > option is to suppress them and handle the result based on the return > value > > of the statement. > > > > -- > > Ferenc Kovács > > @Tyr43l - http://tyrael.hu > > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
Unless you are deleting thousands of files in a tight loop, the overhead involved won't make any difference for your application. In general your application is throwing many errors, even "benign" E_STRICT or E_NOTICE you are already incurring a performance hit. On Mon, Oct 17, 2011 at 3:49 AM, Ferenc Kovacs wrote: > On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev wrote: > >> Hi! >> >> >> On 10/16/11 5:54 PM, Sebastian Bergmann wrote: >> >>> Such a performance regression sounds like an appropriate "punishment" to >>> me for deploying bad code ;-) >>> >> >> By bad code you mean not obsessively checking for stuff that is of no >> importance to them as programmers and is only required because language >> implementers decided to go B&D on their users? ;) >> >> I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null. >> I think it's bad we make people do that. >> >> > and there are cases when you can't avoid triggering errors (like trying to > delete delete a while which can be deleted concurrently) so your only > option is to suppress them and handle the result based on the return value > of the statement. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev wrote: > Hi! > > > On 10/16/11 5:54 PM, Sebastian Bergmann wrote: > >> Such a performance regression sounds like an appropriate "punishment" to >> me for deploying bad code ;-) >> > > By bad code you mean not obsessively checking for stuff that is of no > importance to them as programmers and is only required because language > implementers decided to go B&D on their users? ;) > > I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null. > I think it's bad we make people do that. > > and there are cases when you can't avoid triggering errors (like trying to delete delete a while which can be deleted concurrently) so your only option is to suppress them and handle the result based on the return value of the statement. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
Hi! On 10/16/11 5:54 PM, Sebastian Bergmann wrote: Such a performance regression sounds like an appropriate "punishment" to me for deploying bad code ;-) By bad code you mean not obsessively checking for stuff that is of no importance to them as programmers and is only required because language implementers decided to go B&D on their users? ;) I personally hate to see all these isset($foo['bar'])?$foo['bar']:null. I think it's bad we make people do that. -- 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] #60038 SIGALRM cause segfault in php_error_cb
On 10/12/2011 07:59 AM, Stas Malyshev wrote: Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. Such a performance regression sounds like an appropriate "punishment" to me for deploying bad code ;-) -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
Hi! do you think this is worth fixing (in 5.4 trunk)? (as zend_signal was introduced, and this fix will cost litte perf). OK, if it doesn't cost performance then I guess it's fine to apply it. -- 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] #60038 SIGALRM cause segfault in php_error_cb
2011/10/13 Kalle Sommer Nielsen : > Hi > > 2011/10/13 Xinchen Hui : >> Hi: >> If send signal enabled, no system will be called. >> >> Thkans >> > > What about systems without Zend Signal Handling, like Windows? hmm, I have updated the patch, the fix only take affect when ZEND_SIGNALS defined. :) thanks > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > -- 惠新宸 laruence Senior PHP Engineer http://www.laruence.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
Hi 2011/10/13 Xinchen Hui : > Hi: > If send signal enabled, no system will be called. > > Thkans > What about systems without Zend Signal Handling, like Windows? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
s,send,zend, Sent from my iPhone 在 2011-10-13，8:16，Xinchen Hui 写道： > Hi: > If send signal enabled, no system will be called. > > Thkans > > Sent from my iPhone > > 在 2011-10-12，22:59，Stas Malyshev 写道： > >> Hi! >> >> On 10/12/11 7:50 AM, Ilia Alshanetsky wrote: >>> Seems like a fine solution, performance loss would occur only when >>> error happens... >> >> Note that on 99% of real PHP code, dozens of "errors" may happen due to >> multitude of notices and E_STRICTs that we have now and we have no means to >> disable until the very last moment before printing them. If each of them >> would cost two system calls, we may have a serious performance problem. >> -- >> 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] #60038 SIGALRM cause segfault in php_error_cb
Hi: If send signal enabled, no system will be called. Thkans Sent from my iPhone 在 2011-10-12，22:59，Stas Malyshev 写道： > Hi! > > On 10/12/11 7:50 AM, Ilia Alshanetsky wrote: >> Seems like a fine solution, performance loss would occur only when >> error happens... > > Note that on 99% of real PHP code, dozens of "errors" may happen due to > multitude of notices and E_STRICTs that we have now and we have no means to > disable until the very last moment before printing them. If each of them > would cost two system calls, we may have a serious performance problem. > -- > 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] #60038 SIGALRM cause segfault in php_error_cb
Hi! On 10/12/11 7:50 AM, Ilia Alshanetsky wrote: Seems like a fine solution, performance loss would occur only when error happens... Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem. -- 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] #60038 SIGALRM cause segfault in php_error_cb
Seems like a fine solution, performance loss would occur only when error happens... On Tue, Oct 11, 2011 at 5:30 AM, Laruence wrote: > Hi: > I filed a bug about SIGALRM(or SIGPROF) has chance to cause > segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038 > > do you think this is worth fixing (in 5.4 trunk)? (as zend_signal > was introduced, and this fix will cost litte perf). > > thanks > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
Hi: I filed a bug about SIGALRM(or SIGPROF) has chance to cause segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038 do you think this is worth fixing (in 5.4 trunk)? (as zend_signal was introduced, and this fix will cost litte perf). thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
