PHP 4.4.4 vs Perl 5.8.7 for Object Oriented server code

[www.gerardvignes.com]

Hi,

Have you run into a situation where you had to switch from PHP 4.x.x
to Perl 5.x.x in order to get better performance?

I am using an OO approach to PHP for my website's server code. There
is one tiny script, with dozens of small objects. Each object is in a
separate source file.

It is a bit slow, even when the code doesn't do much DiskIO or MySQL.

My webhost (NetSol) uses PHP 4.4 running on Apache 1.3 and Linux.

I have to option to use Perl 5.8.7. That is the only alternative they
give me at this time.

Without doing the rewite, I am trying to determine if I can expect any
real improvement in performance.

Have you seen or do you know of such a scenario where you get better
performance from Perl than from PHP?

Thanks,

Gerard Vignes
http://www.GerardVignes.com
Seattle, WA

[Michael Fesser]

..oO(www.gerardvignes.com)

>Have you run into a situation where you had to switch from PHP 4.x.x
to Perl 5.x.x in order to get better performance?

I am using an OO approach to PHP for my website's server code. There
is one tiny script, with dozens of small objects. Each object is in a
separate source file.

Same here. A lot of small, highly specialized components. Works very
well and is quite easy to maintain and extend, but the problem is the
overhead in object instantiation, since all these objects have to be
created again and again with every single page request. In fact I'm
kinda reaching the limit of what makes sense to do with OOP in PHP.

But this is something that can't be easily solved with PHP alone.

>It is a bit slow, even when the code doesn't do much DiskIO or MySQL.

My webhost (NetSol) uses PHP 4.4 running on Apache 1.3 and Linux.

Ugly. Much better would be PHP 5.2 (improved memory manager) and a
bytecode cache like APC, which can really speed things up.

>I have to option to use Perl 5.8.7. That is the only alternative they
give me at this time.

Without doing the rewite, I am trying to determine if I can expect any
real improvement in performance.

I don't use Perl (I simply don't like it), so I can't say much about its
OOP performance. But I wouldn't expect too much of an improvement.
Whether you create 40 objects in PHP or in Perl - the main problem
remains.

On the long run the solution for me will most likely be an application
server, which avoids the repeated re-creation and re-initialization of
all my application objects. Then they are created just once when a new
session is started and remain in memory, ready to handle any requests.

Micha

[Curtis]

On Mon, 29 Jan 2007 07:47:01 -0800, Michael Fesser <ne*****@gmx.dewrote:

.oO(www.gerardvignes.com)

>Have you run into a situation where you had to switch from PHP 4.x.x
to Perl 5.x.x in order to get better performance?

I am using an OO approach to PHP for my website's server code. There
is one tiny script, with dozens of small objects. Each object is in a
separate source file.

Same here. A lot of small, highly specialized components. Works very
well and is quite easy to maintain and extend, but the problem is the
overhead in object instantiation, since all these objects have to be
created again and again with every single page request. In fact I'm
kinda reaching the limit of what makes sense to do with OOP in PHP.

But this is something that can't be easily solved with PHP alone.

>It is a bit slow, even when the code doesn't do much DiskIO or MySQL.

My webhost (NetSol) uses PHP 4.4 running on Apache 1.3 and Linux.

Ugly. Much better would be PHP 5.2 (improved memory manager) and a
bytecode cache like APC, which can really speed things up.

>I have to option to use Perl 5.8.7. That is the only alternative they
give me at this time.

Without doing the rewite, I am trying to determine if I can expect any
real improvement in performance.

I don't use Perl (I simply don't like it), so I can't say much about its
OOP performance. But I wouldn't expect too much of an improvement.
Whether you create 40 objects in PHP or in Perl - the main problem
remains.

On the long run the solution for me will most likely be an application
server, which avoids the repeated re-creation and re-initialization of
all my application objects. Then they are created just once when a new
session is started and remain in memory, ready to handle any requests.

Micha

Perl is an awesome language, in my opinion. Getting used to its OOP
facilities can be a bit of a challenge, though. Unlike PHP, it makes use
of namespaces.

It is unlikely that PHP is causing such a significant bottleneck. It's
more likely that the trouble is at the server or database.

My apologies if the lines in this message weren't wrapped properly, I'm
testing newsreaders (trying Opera, very cool, so far). There didn't appear
to be a setting to control this, so I'm hoping it knows better.

--
Curtis

[www.gerardvignes.com]

Thanks everyone for reading and responding,

I am going to stick with PHP (4.4 sadly) and try a different approach:

1. consolidate several objects into one script, eliminating requires
and reducing script loads

2. reducing the number of objects created to minimum (coarse-grained
objects)

I appreciate your input,

Gerard Vignes
http://www.GerardVignes.com
Seattle, WA

[irezvin]

Thanks everyone for reading and responding,

>
I am going to stick with PHP (4.4 sadly) and try a different approach:

1. consolidate several objects into one script, eliminating requires
and reducing script loads

2. reducing the number of objects created to minimum (coarse-grained
objects)

I had same problems and I can recommend you several things.

1. Carefully pass your objects BY REFERENCE - always, when possible,
use $foo = & $bar if $bar is an object; same for the functions that
return objects; it's very important for PHP 4, also it prevents PHP
from blowing up your memory with copies of objects.
2. Initialize your objects (and, if it is possible, load your classes)
immediately before use - read good article here
http://www.sitepoint.com/blogs/2004/...zy-php-part-1/
Also on that: autoloading of classes in PHP5 totally rocks, but in
PHP4 there is a sense in creating a factory function that will
autoload classes (I did that and it really helps).

3. I tried the consolidation into one script (I had over 50 classes)
and can recommend you to do it automatically (for example concat them
into one file just in order of inheritance), because such large file
is extremely difficult to maintain by-hand. Also note that step 2
eliminates the need in step 3 (unless you surely and absolutely know
that you will need all these classes on EVERY request). And I also
haven't noticed any significant performance increase with many classes-
in-one-file vs. many classes in separate file.

Anyway, good luck!

[www.gerardvignes.com]

Thanks I.Rezvin!

I am probably passing by value. Ugh! I need to fix that mess.

I also really appreciate the link to Lazy PHP. It looks like a great
article.

I already had to use a batch script to put all my client-side
JavaScript object files into one optimized script for deployment. That
made a tremendous improvement for the page loading time. I'm going to
do the same for the PHP code.

You have excellent advice. I am indebted to you.

Gerard
On Feb 1, 5:07 pm, "irezvin" <[e-mail]:
....

I had same problems and I can recommend you several things.

1. Carefully pass your objects BY REFERENCE - always, when possible,
use $foo = & $bar if $bar is an object; same for the functions that
return objects; it's very important for PHP 4, also it prevents PHP
from blowing up your memory with copies of objects.

2. Initialize your objects (and, if it is possible, load your classes)
immediately before use - read good article here
http://www.sitepoint.com/blogs/2004/...zy-php-part-1/
Also on that: autoloading of classes in PHP5 totally rocks, but in
PHP4 there is a sense in creating a factory function that will
autoload classes (I did that and it really helps).

3. I tried the consolidation into one script (I had over 50 classes)
and can recommend you to do it automatically (for example concat them
into one file just in order of inheritance), because such large file
is extremely difficult to maintain by-hand. Also note that step 2
eliminates the need in step 3 (unless you surely and absolutely know
that you will need all these classes on EVERY request). And I also
haven't noticed any significant performance increase with many classes-
in-one-file vs. many classes in separate file.

Anyway, good luck!

[www.gerardvignes.com]

I tried combing PHP objects into a much smaller number of scripts,
making sure to group by usage. I couldn't measure any difference from
using on script per file. That echoes what I.Rezvin said previously.

I am already using a variety of lazy evaluation, embedding
require_once(whatever) in conditional statements. I checked this, and
it works properly on both PHP 5 and PHP 4.4. The script will not be
included unless that branch of the conditional is reached and
executed.

I started modifying my code, inserting /* & */ to stipulate object
references in a variety of places where unnecessary object copies were
made. This theoretically allows my code to work with PHP 5, and yet be
easily modified using a SED pattern to work with PHP 4. I am not
convinced that this is the best approach, given that the code becomes
a bit messy and requires an additional step prior to deployment.

I have at least identified some areas that require & references:

1. $myInstance = & new MyObject();

2. function myMethod(& $myArgument) { ... }

I am not certain which of the following is required (or both):

A. return & $myGeneratedObject;
or
B. $myNewObject = & $myInstance->myMethod($myValuet);

Thanks,

Gerard Vignes
http://www.GerardVignes.com
Seattle, WA