Re: [PHP-DEV] [PATCH] Redirect on Error

[George Schlossnagle]

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.


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php