On Fri, August 20, 2010 1:15 pm, StanisÅ?aw Findeisen wrote: > On 2010-08-20 17:10, Bostjan Skufca wrote: > 1. What optimizations does PHP interpreter make? I guess it should be > able to check file modification time and cease to compile it again and > again. Is this correct? PHP does not do that. There are opcode caches such as APC which do. And APC is rumored to be rolled into the next release, or perhaps is available in 5.3 already. > There is some bytecode form, right? Yes, PHP compiles to bytecode. > What else does it do? For instance if there is a big, immutable class > in > the application (say it contains a bunch of constant XML documents, > hardcoded into the source): will the interpreter notice that and > instantiate this class only once across multiple requests? No. PHP is a "shared nothing" architecture, by design. Scaling is accomplished by simply tossing more boxes in, with no worries about shared resources being out of sync. > What if this class generates side effects (like printing "hello world" > in the constructor) and what if it doesn't? PHP has nothing so formal about "side effects" or the lack thereof. That's up to the application developer to worry about. > 2. I guess PHP application wide cache is quite a different story? For > the worker processes are separate... Or maybe PHP interpreter itself > provides any means for that?? Again, it's a Shared Nothing architecture by design. It's not Java. It's not even ASP. It's PHP, and we *like* it that way. KISS > 3. Does PHP interpreter maintain any state across different requests > within the context of a single Apache worker process? If so, what does > this state contain? PHP does not maintain state, as HTTP is a stateless protocol. Technically, this is not 100% true, as I'm sure there is *something* down in the guts of the C code that has some kind of "state" but it's sure not available in userland PHP code. > 4. Does PHP interpreter maintain any global state within the context > of > a single Apache HTTP server instance? If so, what does this state > contain? No. > 5. What about system wide PHP interpreter state?... No. > 6. I heard some nasty rumors that PHP interpreter resource management > is > somewhat problematic (memory leaks, or something), and because of that > those Apache worker processes have to be killed from time to time. > > Could you please comment on this? It is trivial to create long-running scripts that "leak" memory by not clearing variables. PHP's garbage collector is simplistic, even rudimentary in nature. But most PHP scripts are designed to spit out a web page in microseconds. At the end of the script, everything is released. So, it *CAN* be problematic if: A) you're using PHP for long-running scripts and B) you don't have enough sense to wipe out variables that will keep tons of RAM in use. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
