[ILUG] [OT] Perl vs php?

[Donncha O Caoimh]

Dave Wilson wrote:
> 
> On Wed, Nov 10, 1999 at 12:13:18PM -0000, Barry Redmond wrote:
[snip]
> For ease of programming: Perl is always fun, but PHP is well
> documented and surprisingly intutive. It only took a few hours
> total to build slashnull.org (linux+apache+mysql+php) - including
> installing the machine and learning PHP from scratch. I was *really*
> impressed at how quickly the code just seemed to fall together in PHP.

I'd almost agree with you there. I had a few projects under my belt in
Perl before I started on PHP and found it to be a fairly uphill struggle
figuring out PHP. I was used to using perl in the cgi-bin directory and
this embedding code in the web page was something new. 
Maybe I should blame phplib here because it's quite a complex add-on
library to PHP, and I didn't take the time to read the documentation 3
or 4 times as I should have done.. 
Once over that hurdle, PHP is amazing to use. Defining and using classes
is simple, although there are a few cavaets when using subscripts to
hashes when inside a string..

> 
> For execution speed: no contest, choose PHP and build it into the web
> server. Forking a separate CGI process is a serious overhead, and Mod::Perl
> is a bit heavy to have multiple copies permanently resident in RAM.

I brought this up before arguing that PHP was faster but Perl is quite a
bit faster at purely mathematical and looping tasks. I'd choose PHP to
build an emcommerce site, but Perl to code the backend of a statistics
page, or a streaming data server. Perl is heavy in each HTTPD child but
extra RAM takes care of that.

> 
> PHP gives you a light but powerful web server with a direct interface
> to the database, no messing. It's the neatest architecture since
> AOLserver+Tcl, and a lot easier to debug.

Almost. I haven't used php itself to access a database but the examples
I've seen aren't very abstracted. (ie. mysql centric commands) 
Add phplib on top and it's very abstracted, and allows for easily
building extra functionality in inherited classes.
Debugging is simple alright :)

> 
> > The database contains two tables with about 40000 rows in one
> > and 20000 in the other.
> 
> Decent size. All my databases have been tiddlers. But this will be
> down to the speed of the database, not the web server or the scripting
> language. Can anyone vouch for MySQL under these circumstances?

I did a comparision a while back. PHP compiled into the server versus a
C program launched using the standard CGI interface. The exercise was to
read a few thousand rows from a MySQL database and print them to STDOUT
(ie. the browser).
The PHP script read stuff row by row using phplib and took 13 seconds,
while the compiled C program took less than 2 seconds if memory serves.
Of course the C program used the MySQL interface so the PHP code would
have been more portable between databases.
I could have used just PHP without phplib and grabbed all the data into
a cursor in one go but then you lose the unified database interface that
phplib provides..

MySQL will handle that amount of data easily. Just make sure to run
isamchk on them every week or so to clear out old records. (_very_
important with large amounts of data and frequent updates/deletes) If
you find MySQL is running at 90% of CPU run isamchk.. 

Don't try and run "select MAX()" on tables of that size in MySQL. CPU
usage will skyrocket! Perhaps indexed and isamchked every day yeah but..

MySQL is a very low level database which I'm sure Oracle/DB2 etc
programmers would balk at but it's damn fast.
If they're going to be read only databases you could pack the tables.
You have to register the software though, but it's expensive. 

Hope that helps,
Donncha