Quite boring to read this thread where two persons argue about something
abstract. Stas, can you give a real life example where your patch is necessary..?
--Jani
Stanislav Malyshev wrote:
Hi!
Unless your code is "ridden" or if you prefer "filled" with @ and/or
errors the speed improvement would be next to impossible to measure
since you'd be literally saving microseconds. You'd need to have a
Microsecond here, microsecond there - this stuff adds up. And 2-3
mallocs of substantial size (IIRC some messages are long enough so
emalloc caches do not apply) plus whole printf ordeal - even twice in
some cases - are not that small change, especially if it could happen
repeatedly. Of course it alone won't make you 50% speedup, but even 0.5%
here and 0.5% there add up.
BTW, if you benchmark only this thing (yes, I know, it's not realistic
:) the difference is very, very measurable - error reporting slows down
operation with ignored error 3-4 times. I think if I proposed an
improvement that would speed up certain set of opcodes 3 times that'd be
worth having, not?
to make a reliably measurable difference. More over, if the user
defines an error handler, which many applications, frameworks, etc...
do then your improvement is next to invisible in between the overhead
of executing PHP code to process the error.
The thing is you would be in control of which errors too feed to the
error handler and which not to. That's exactly the point - giving you
the tools to control it. Including tools to deal with "noisy" code the
way you like - which may be your way, my way or any way in between. If
you don't care - default changes nothing, but if you do, you have the
means to make it run faster.
Vast majority of E_NOTICEs are not fixed not because people don't want
You are still focused on one particular case of E_NOTICE. It's not
(only) what's it about, it's bigger.
set to ignore those errors. And E_NOTICES btw often could've let
people know about security faults before they were abused, such as
uninitialized variables and array keys that could be injected via
register_globals, extract() function, etc...
Yes, yes - if only they were actually *seen* by anybody. The case we
discuss here is when they *are not* seen anyway. So I don't see how your
argument applies. Your argument is about entirely different thing which
I do not argue with you about - that some warning should not be
disabled/hidden. I agree with you. But some OTHER warnings should be,
and that's the case I want to fix.
Stas, my biggest issue is that you are making this configurable value
that makes this open to abuse, rather then using 0 as default and
matching the error message creation to error reporting settings.
It can be done too, but not having other configuration will disable some
scenarios when you don't want the error to go through usual reporting
mechanisms but want debugger/monitoring system still see it. I
understand that if we designed error_reporting from scratch maybe we'd
just say "one switch for everybody", but since we already have people
that are used to having current system, I made it as flexible as
possible. If people around here think it's too flexible I could just
make it on/off (i.e. same as -1/0 with current patch), it's trivial. I
just wanted to start with max flexibility.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
