On Monday, November 25, 2002, at 10:43 PM, Ilia A. wrote:
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.On November 25, 2002 10:30 pm, George Schlossnagle wrote:There is no proposed patch to affect all these changes. There are fineIf we were talking about a one time script that is execute and forget then you
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)
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.
And if you're running an hosting service for users, performance is sort of out the window anyway.
This is also not as easy as it sounds, for example a gettext a commonlyWell, fortunately, this being an open-source project this burden need not lie with you if you don't want it to.
used tool for localizations, is not thread safe, so we are looking at having
to design a error localization mechanism with a thread safe disk database
system.
I'm somewhere between +0 and +1 on this issue. I think it would be helpful, a nice feature to have. and generally increase accessibility. I don't think that an implementation would necessarily incur overhead unless error functions are being called.
George
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
