in reply to
Re: Re: mod_perl and shared environments don't mix - do they?
in thread mod_perl and shared environments don't mix - do they?
The PHP interpreter is written directly in C. Perl runs (after compilation) as a bytecode interpreter. I think that this is the other main advantage of PHP: response time should be improved by using one layer of interpretation instead of two.Perl does not use bytecode
and there isn't an extra layer of indirection. You'll be better off if you just strike this bit as no part of this is meaningful.
I'm not familar with the internal data representation of PHP, so I can't immediately compare the two languages that way.
I'm not familiar with PHP's guts - apparently you aren't familiar with perl's.
Unfortunately, PHP's strength (interpreter written in C) is also its critical downfall, from a network security perspective. I have advised two clients not to use PHP for publicly exposed scripts because of repeated "arbitrary code execution" buffer overflow bug reports in PHP's POST parameter parsing code...I think I've seen at least three distinct reports of this in 2002. So far, both clients have taken my advice.
Again, this misses the point. Perl is subject to all the same problems. The difference is that perl is vastly more mature and these sorts of issues have just been shaken out by now. There's also some benefit in that CGI.pm's parameter parsing code is written in perl so you only have an exploitable bug if there's something wrong with perl's string handling. Apache::Request though - that's written in C and again it plays in exactly the same ballpark. The difference is again, relative maturity. All this means is that in a few years PHP will be sitting pretty.