I think we should do something along the lines of what Stas is suggesting. The current approach of allocating and sprintf'ing all messages regardless of whether they will ever be used for anything is painful and a huge impediment to adding informative E_NOTICE and E_STRICT messages in the future.
A good example of the benefit of this patch is upgrading a server running older PHP code that causes a lot of E_STRICT messages. The performance hit can be significant to the point where people may downgrade to the older version until they can get around to cleaning up the code. Having the ability to properly turn off E_STRICT such that not only are E_STRICT messages not shown, but they also don't eat up valuable cpu cycles is something we should have done long ago. It is non-intuitive that disabling an error type doesn't also remove the performance hit associated with generating that error message. -Rasmus Jani Taskinen wrote: > 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
