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. This is also not as easy as it sounds, for example a gettext a commonly 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. > On Monday, November 25, 2002, at 10:27 PM, Ilia A. wrote: > > On November 25, 2002 09:59 pm, George Schlossnagle wrote: > >>> By the way, could you please advise by how much I will need to > >>> increase the > >>> power of my server(s) to maintain the same level of performance? > >> > >> Why would this need to kill your performance if you're not throwing > >> errors? > > > > Because errors need to be loaded into memory by some mechanism, stored > > in a > > hash table? Meaning that during startup I will be penalized for this > > process. > > Hash table has it own overhead as well meaning that PHP memory usage > > will > > increase, for a server running 200-300 apache children constantly even > > a > > small increase will count. > > This will also make PHP shell scripting impractical due to the high > > start > > costs of a PHP binary. > > > > Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
