in reply to Re: Perl and Infiltrating PHP Workplaces
in thread Perl and Infiltrating PHP Workplaces
Perrin: I've read that PHP is comparable in speed to mod_perl, but if all you have available is CGI (as is the case on most remote hosting accounts?), then PHP is going to run significantly faster. Unless I'm missing something obvious here.
What you read is wrong.
CGI is not Perl, but a protocol that allows a webserver to communicate with specially designed programs. These programs can be written in any language, including both Perl and PHP. The only requirement is that the CGI program is executable.
CGI is slow, so both Perl and PHP offer an integrated solution, that runs within Apache. These solutions are called mod_perl and mod_php respectively.
In general --though exceptions exist-- mod_perl is faster than mod_perl, and CGI+Perl is faster than CGI+PHP. It's incredibly silly to compare speeds of mod_php versus CGI, as the integrated solution will win from the heavy communications protocol that involves forking off a new process for each pageview.
It's true, that if all you have are mod_php and CGI, the mod_php solution will probably run faster. But this is only relevant if you're tied to cheap bulk hosting. Businesses that hire developers usually have enough funds to configure their own server, or to have a better equipped shared hosting account. A few hours of development is much more expensive than the difference between cheap bulk hosting and your own supplier-managed dedicated server. By using a scalable, programmer-efficient language like Perl, you save more than just a few hours, if your developers are competent.
As for being faster to code, it's faster for small things to work from one file and insert a few lines of code, than it is to work with a templating system and keep the code and HTML separate.
It is, but maintenance will suck real soon after that. Clean code is more work, but that is an investment that will save time, and thus money, in the future. Only if your business is small and never gets new employees, you can do without code separation and documentation. But most businesses want to grow, and thus have to invest in a stable foundation for future activities. Code mixed with content is a fragile base. (And don't forget that this isn't Perl versus PHP anymore, as you can easily use content and code with Perl. It takes only a few regexes, or one of many CPAN modules, to accomplish this. And, of course, it is possible to cleanly separate code from content with PHP -- just don't expect the result to perform well.)
|
|---|