> 1.Speed: If you use mod_perl or fastcgi kind of deals
> (which are based on threadding instead of forking), I
> don't think PHP is considerably faster than perl? Is
> that the case?
Threading instead of forking? None of these do either. Apache is a
pre-forking multi-process server and both PHP and mod_perl are part of
these pre-forked processes. Neither mod_perl nor PHP do any threading nor
forking.
> 2.Database Connection: What is the BIG advantage of
> PHP here? Using DBI packages for perl, and fastcgi for
> db connection pooling, you can achieve the same thing,
> I guess. It just looks like PHP has some of these
> libraries embedded in the core language, but the idea
> is same--implementing the native db protocol over
> sockets?
No difference.
> 3.Shared Memory, global variables, etc: I was
> expecting a better interface for this in PHP, and I
> was really disappointed to see that developers have to
> use O/S level shared memory. First of all, this is not
> available on Windows???? And, it is kind of messy and
> hard to use, especially when you compare this to
> Java's static variables.
Again, the architectural difference makes this a lot easier to do in a
single-process JVM scenario. Note that such a single-process JVM
architecture which maintains static objects is very hard to scale cleanly.
> 4.Session Management: If you use files to manage
> sessions, same thing can be achieved in perl.
> Regarding in memory session management, as far as I
> know, FastCGI can share variables among sessions, so
> it shouldn't be hard to write a session manager in
> perl as well.
Probably true.
> 5.Architecture: I couldn't find any doc about how PHP
> works. And any answer to important questions, like
> -How does compilation process work? Does the PHP
> engine compile htmls first time a request is made to
> that html and use that compiled code later on(just
> like JSPs), or does it compile everytime? Is PHP
> engine an interpreter, jvm-like byte-code
> generator/executer or a compiler?
> -How does threadding work? How can you cache stuff,
> etc.?
> -What is the generic lifecycle of a request/response?
PHP is a 2-stage interpreted language. First pass generates opcodes,
second pass executes the opcodes. Various add-on caches and optimizers
can cache the opcodes and thus skip the interpreter step. Doesn't usually
win you a whole lot unless you have quite complex logic in your pages
though. The interpreter is pretty fast.
There is no threading in PHP. The web server provides the base
thread/process architecture.
The lifecycle of a request/response matches the lifecycle of an HTTP
request/response.
> 6. Embedding scripts in HTML: Well, I mean, this is
> similar to JSP, but what the hell, you can use <<AA
> ..... AA; syntax and embed any string you want at any
> point by mixing and matching HTML and perl code. I
> mean, yeah PHP is easier, but it is not considerably
> easier, I believe.
Probably not.
> I have been searching the internet to find some
> serious comparisons, but all I found was a stupid page
> which compares the syntax rather than functionality.
>
> As I said, I really need to start developing soon, and
> I would appreciate comments regarding this issue.
Basically any language can be used to write web apps. There is nothing in
PHP you can't do in Perl, ASP, Cold Fusion, Python or JSP. PHP just
happens to package things together in a easy to comprehend way and
everything you read about PHP is geared towards the Web problem whereas in
the case of more general-purpose scripting languages it can be confusing
trying to figure out how to approach the web problem.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
