Re[4]: as always - manual is not for IT

Igor <[email protected]>
Newsgroups gmane.comp.web.fastcgi.devel
Organization ROL
Message-ID <[email protected]>
Hello Jonathan,

Saturday, January 21, 2006, 2:16:27 AM, you wrote:


JC> I am pretty sure that my setup is correct.  To verify my setup, I
JC> limit the php-fcgi children to 1, and I use strace to trace that child
JC> process.  On the other terminal, I setup ab2 to get main.php twice:

JC> ab2 -n 2 http://localhost/main.php

JC> The attached strace file shows that each include file is
JC> open/read/close twice.

JC> Do you think PHP engine actually translates

    Read this:
    http://us3.php.net/manual/en/function.require.php
    and even more specific information on how PHP's includes work
    is available  here:
    http://us3.php.net/manual/en/function.require-once.php

    "statement includes and evaluates the specified file during the
    execution of the script"
    the key words are "during the execution"

    So much for PHP... That means that even in FastCGI mode PHP
    will continue to spend time on making useless includes each time a
    script is invoked.
    
    This appears to be the one big difference between PHP and Perl
    interpreters (or at least of fastcgi for the both languages).

    Perl will optimize the code before it starts it.
    Even if you use "require" not "use" in Perl script header, when fascgi is
    started you may delete the required module and it won't be
    required until the fastcgi process is alive or there is no new
    fascgi server to start. The drawback of this approach is a
    relatively slow start (I think Perl has some kind of a
    preprocessor). May be PHP developers consciously built
    this behavior in the PHP's design to speed it up.
    
    I only wish there were an alternative to this default behavior in PHP.
    This behavior might give some ground for the following assumption:
    Perl in Fast-CGI mode works even faster than PHP in any mode.

    It appears that if you're expecting performance gain of PHP
    fast-cgi - do not seek it in include optimization. PHP's includes are
    proved to be slow and inefficient in many ways and this Fast-CGI
    issue.
    
    Sorry, for propagating the wrong ideas about PHP's includes
    working faster in FastCGI mode. Obviously the assumption was
    not correct.
    

JC> everything into one unit before the intepretation or it works like a
JC> bash interpreter reading and executing line by line?

    Try require, the chances are low that it will work differently but
    you may try it anyway.


-- 
www.rol.ru
Best regards,
 Igor                            mailto:[email protected]

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.