Don't forget that some users make use of set_error_handler(). This results
in a user function being called with quite a bit of parameter data EVEN if
an @ is prepended to the statement. The error level is temporarily set to
0 for the duration of the statement.
That's why a new internal function addresses the issue so cleanly.
~Jason
At 4/17/2004 05:03 PM +0800, Alan Knowles wrote:
Yeah looks like 50% slower..!
Wouldnt it make more sense to optimize @ + fetch_var(), rather than
introduce new syntax?Regards
AlanMarcus Boerger wrote:
Hello Alan,
Saturday, April 17, 2004, 2:36:55 AM, you wrote:Jason Garber wrote:
In our code, you will find many blocks looking like
$CUST_ID = (integer) (isset($_POST['CUST_ID']) ? $_POST['CUST_ID'] : 0);
so how is that different from
$CUST_ID = (integer) @$_POST['CUST_ID'];@ is damn slow
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
if you make @ fetch_var it's own opcode,
- on isset() = true you do a straight return value. .. No touching
error handler etc.. (this should be v.fast) - on isset() = false you modify the error_handling + do the callback
(this is slow...)
You have effectively solved the performance issue 99% of the time....
Regards
Alan
Jason Garber wrote:
Don't forget that some users make use of
set_error_handler(). This
results in a user function being called with quite a bit of parameter
data EVEN if an @ is prepended to the statement. The error level is
temporarily set to 0 for the duration of the statement.That's why a new internal function addresses the issue so cleanly.
~Jason
At 4/17/2004 05:03 PM +0800, Alan Knowles wrote:
Yeah looks like 50% slower..!
Wouldnt it make more sense to optimize @ + fetch_var(), rather than
introduce new syntax?Regards
AlanMarcus Boerger wrote:
Hello Alan,
Saturday, April 17, 2004, 2:36:55 AM, you wrote:Jason Garber wrote:
In our code, you will find many blocks looking like
$CUST_ID = (integer) (isset($_POST['CUST_ID']) ? $_POST['CUST_ID']
: 0);so how is that different from
$CUST_ID = (integer) @$_POST['CUST_ID'];@ is damn slow
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com--
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
This doesn't help anything in the case where the thing isn't set
and you don't care that it isn't set, and don't want to call
the error handler at all.
--Wez.
----- Original Message -----
From: "Alan Knowles" alan@akbkhome.com
To: "Jason Garber" jason@ionzoft.com; internals@lists.php.net
Sent: Saturday, April 17, 2004 10:20 AM
Subject: Re: [PHP-DEV] Re: [RFC] ifsetor operator
if you make @ fetch_var it's own opcode,
- on isset() = true you do a straight return value. .. No touching
error handler etc.. (this should be v.fast)- on isset() = false you modify the error_handling + do the callback
(this is slow...)
You have effectively solved the performance issue 99% of the time....Regards
Alan
Jason Garber wrote:
Don't forget that some users make use of
set_error_handler(). This
Which reminds me that the documentation should be updated to reflect the
additional parameter error_types to set_error_handler. (Without it you
end up calling the user error handler lots even if you disabled
E_NOTICE for error_reporting).
Maybe the test case at
http://cschneid.com/php/php5/set_error_handler.phpt
could also be added to the distribution.
- Chris
Christian Schneider wrote:
Which reminds me that the documentation should be updated to reflect the
additional parameter error_types to set_error_handler. (Without it you
Oops, fell into the same trap again. My browser is set to german so I
automatically saw the german version of the page which is outdated.
Quickly changed my browser settings to not make the same mistake again :-)
Which brings me back to yet another point: The various languages of the
documentation should state when they are outdated in respect to the
english version.
- Chris
Christian Schneider wrote:
Which reminds me that the documentation should be updated to reflect the
additional parameter error_types to set_error_handler. (Without it youOops, fell into the same trap again. My browser is set to german so I
automatically saw the german version of the page which is outdated.
Quickly changed my browser settings to not make the same mistake again :-)Which brings me back to yet another point: The various languages of the
documentation should state when they are outdated in respect to the
english version.
I wrote a script years ago that figured this out and showed a little
report card for each translation. I think someone took that and ran with
it, but I have no idea where the current version lives today.
-Rasmus
Revision checking is available in the php documentation build system
perfectly, but it is not (yet) exposed to the end users (outdated
translations are not marked). This will be one of the things solved by
livedocs, sometime in the future.
Goba
Which reminds me that the documentation should be updated to reflect the
additional parameter error_types to set_error_handler. (Without it youOops, fell into the same trap again. My browser is set to german so I
automatically saw the german version of the page which is outdated.
Quickly changed my browser settings to not make the same mistake again :-)Which brings me back to yet another point: The various languages of the
documentation should state when they are outdated in respect to the
english version.I wrote a script years ago that figured this out and showed a little
report card for each translation. I think someone took that and ran with
it, but I have no idea where the current version lives today.-Rasmus