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
>> Alan
>>
>>
>> Marcus 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
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
