Jon Anderson wrote:
Take this with a grain of salt. I develop with PHP, but I am not an
internals guy...
[EMAIL PROTECTED] wrote:
Are the include files only compiled when execution hits them, or are
all include files compiled when the script is first compiled, which
would mean a cascade through all statically linked include files. By
statically linked files I mean ones like "include ('bob.php')" - i.e
the filename isn't in a variable.
Compiled when execution hits them. You can prove this by trying to
conditionally include a file with a syntax error: if (false)
include('script_with_syntax_error.php'); won't cause an error.
Good idea.
Secondly, are include files that are referenced, but not used, loaded
into memory? I.e Are statically included files automatically loaded
into memory at the start of a request? (Of course those where the
name is variable can only be loaded once the name has been
determined.) And when are they loaded into memory? When the
instruction pointer hits the include? Or when the script is initially
loaded?
If your include file is actually included, it will use memory. If it
is not included because of some condition, then it won't use memory.
I wonder if that's the same when a cache/optimiser is used. Probably.
Maybe I'll check.
Are included files ever unloaded? For instance if I had 3 include
files and no loops, once execution had passed from the first include
file to the second, the engine might be able to unload the first
file. Or at least the code, if not the data.
If you define a global variable in an included file and don't unset it
anywhere, then it isn't automatically "unloaded", nor are
function/class definitions unloaded when execution is finished.
Once you include a file, it isn't unloaded later though - even
included files that have just executed statements (no definitions
saved for later) seem to eat a little memory once, but it's so minimal
that you wouldn't run into problems unless you were including many
thousand files. Including the same file again doesn't eat further
memory. I assume the eaten memory is for something to do with
compilation or caching in the ZE.
Thirdly, I understand that when a request arrives, the script it
requests is compiled before execution. Now suppose a second request
arrives for the same script, from a different requester, am I right
in assuming that the uncompiled form is loaded? I.e the script is
tokenized for each request, and the compiled version is not loaded
unless you have engine level caching installed - e.g. MMCache or Zend
Optimiser.
I think that's correct. If you don't have an opcode cache, the script
is compiled again for every request, regardless of who requests it.
IMO, you're probably better off with PECL/APC or eAccelerator rather
than MMCache or Zend Optimizer. I use APC personally, and find it
exceptional -> rock solid + fast. (eAccelerator had a slight
performance edge for my app up until APC's most recent release, where
APC now has a significant edge.)
Thanks - that's useful to know.
Fourthly, am I right in understanding that scripts do NOT share
memory, even for the portions that are simply instructions? That is,
when the second request arrives, the script is loaded again in full.
(As opposed to each request sharing the executed/compiled code, but
holding data separately.)
Yep, I think that's also correct.
Fifthly, if a script takes 4MB, given point 4, does the webserver
demand 8MB if it is simultaneously servicing 2 requests?
Yep. More usually with webserver/PHP overhead.
Lastly, are there differences in these behaviors for PHP4 and PHP5?
Significant differences between 4 and 5, but with regards to the
above, I think they're more or less the same.
Thanks Jon. So in summary: use a cache if possible. Late load files to
save memory. Buy more memory to handle more sessions. And it's
conceivable that when caches are used, different rules may apply.
Jeff
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
