good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
In the bad old days, Perl-based CGIs were started by spawning a new interpreter for each request. As you might imagine, this was very expensive and not very scalable. You could be parsing a multi-megabyte flat-file, but start up time would still be the limiting factor for speed. These days, you can use mod_perl to embed the interpreter right into Apache (there are similar solutions for other web servers). Though there are places with a lot of legacy scripts (like where I work) that simply can't run under mod_perl. As far as the embedded interpeter goes, mod_perl and mod_php do the same thing for their respective language (mod_perl also gives you access to the underlieing Apache API--I'm not sure if mod_php does this). PHP as a language is basically Perl with all the fun parts taken out. Some would argue that the "fun parts" make Perl hard to learn. Even so, whenever I dabble in PHP, I always seem to knock against a problem that is easily solved in Perl, but takes a lot of hoop-jumping to do in PHP, despite the apparent similarities. Admittedly, this may have more to do with my relative experiance with Perl and PHP. Don't make the mistake of saying CGI == Perl. CGI is just a standard for how http servers translate data coming from an http client to a user-space program. Any time you see a server-side program take over generating a page, it's using CGI or something that looks suspiciously similar. ---- Note: All code is untested, unless otherwise stated In reply to Re: CGI/Perl vs PHP
by hardburn
|
|