Re: [PATCH] Redirect on Error

On Monday, November 25, 2002, at 11:29 PM, Ilia A. wrote:

On November 25, 2002 10:57 pm, George Schlossnagle wrote:

On Monday, November 25, 2002, at 10:43 PM, Ilia A. wrote:

On November 25, 2002 10:30 pm, George Schlossnagle wrote:

There is no proposed patch to affect all these changes. There are fine ways to print errors that don't necessitate having them loaded at run time. They could be in a dbm file, or even a flat file hierarchy and loaded on demand. This would not be as fast as a hash table, but when you're actually printing errors, a slight overhead seems acceptable (to me, ymmv)

If we were talking about a one time script that is execute and forget then you are absolutely right. But what about if a web server enviroment where a child/thread can remain in memory indefinitely. Or a web hosting enviroment where the admin has no control over the script of the users, loading & (unloading?) of the error messages database will add overall overhead non the less.

dbm lookups are fast, as are (to a lesser extent) file system lookups. Neither consume any process memory. Neither require an entire database to be loaded, simply to have the entry looked up in them.

Nearly any singular operation is fast, the question is what happens when it is done often. For a database stored on disk we are talking at least 2-3 drive seeks + reading of meta information at the start of the database. While it may be negligible for a single process it does add up. Given that this done rarely (hopefuly) it would not result in major performance loss, however there will be a performance loss non the less.

If you're throwing errors your script isn't working right anyway. syslog() logging is also extremely slow, especially if you're logging to a network host, but that's still supported in php. There are plenty of shocking inefficiencies in php. Adding one in the case of user error (which if you're running a site where an extra 3 drive seeks per error is a serious issue you should be disciplined enough not to be having at all) seems like a pittance to me.

Well, fortunately, this being an open-source project this burden need not lie with you if you don't want it to.

I dislike the idea because I believe this idea is going to make PHP more confusing and ultimately harder to use, which is the exact opposite of what this change attempts to accomplish. Fortunately this being an open-source project it is also possible to make your own version free of bloat :)

It's hard for me to decide whether this is bloat or not. 2700-some builtin functions shipping with php seems much more like bloat to me than providing option i18n error messages to people who would prefer to read them.