Posted by Jamie on 03/15/07 13:38

In <z5KdnSo5vd-qpmTYnZ2dnUVZ_ternZ2d@comcast.com>,
Jerry Stuckle <jstucklex@attglobal.net> mentions:
>True, if you're running 1K inserts per second it can make a difference.
> For most perl and PHP isn't doing nearly that much. And if you need
>the performance boost, a compiled language would provide a greater boost
>than just using placeholders.

The thing is, this cache happens server-side (server relative to the DBM
server)

In the case of n-number of web server processes, it matters because you'll
likely have fewer DBM resources. Compiled web programs won't even help
you here as this stage happens on the database.

But, this is pretty much a moot point for mysql, unless mysql has implemented
placeholders and I haven't heard about it.

I will only add that placeholders also shield you from many SQL injection
bugs. Something that is nice to have around.

>Obviously you don't understand PHP very well. I've been programming
>since the early 4.0.x and currently am at 5.2.1. I can't remember when
>I've had to chance any code for a new release. Use good programming
>practices and upgrades are painless.

It depends on who installed the PHP binary server-side. I've smacked my
head into this wall a number of times. PHP 5.n looked really promising,
I ported my stuff to it.. and soon discovered almost all the ISP's out
there are still using PHP 4... and continue to use PHP 4.

>Now that doesn't mean I haven't rewritten code. But it's been to take
>advantage of new features rather than because a new version required a
>change.

Like, if they had compiled php without POSIX support for example? Thats
the kind of stuff I'm talking about. One place has posix, the other doesn't
and you end up coding around whichever environment is available.

As far as actual code crashing.. I've had numerous problems with PHP reference
handling, looking in apache error logs reveal a segfault depending of
course on your particular copy of php. (PHP5 gets reference handling "right"
in my view, too bad it's flaky)

>This is not to say that sometimes changes may not be needed. The PHP
>developers are doing their best to clean up what has been a mess of a
>language - poorly planned and executed. It's changing, but sometimes
>change is painful.

Oh, I agree. Not a slam against the PHP developers. PHP is great for small
things where you only need a quick mysql query or access to the include()
functions.

Heckuva lot easier than installing perl template modules.

>Fortunately perl was better planned and implemented.

Yea, Larry Wall.. a linguist. You can tell by the way it was designed that
it actually /was/ designed.

>Wrong on both count. I've seen both used in some quite large projects.
>- one perl project I know about was over 250K LOC, for instance. And
>that's perl code - not html.

Spam assassin is another that is quite impressive. It's just that with perl (or
PHP) the rules aren't as "enforced". Perl6 I hear is trying to address this.

>Yep, exception handling was added to PHP, so like with any new addition,
>you can use it in later versions but not in earlier ones. Gee - you
>know, the same thing is true in any product. It's hard to use something
>before it was added.

True. It's just that with the large installed base of PHP4, you'll find
this fact is a real problem.

>No, that's different implementations. But I've never seen this as a
>problem in either PHP or perl. The input document should be arriving
>pretty much all at once, anyway.

As I recall (it's been awhile) doing something like, say, a PUT handler
involved first the PHP engine accepting the request, spooling the data
to a temp file or memory or what have you, setting up it's environment
and THEN calling your script.

Perl on the other hand, not being web centric, gives you the opportunity
to read in from standard input directly if you want, so you could
build an XML tree from the source document /as/ the document is being
posted.

Why not take advantage of the IO-bound time to build a data structure as data
arives? Especially considering you were going to read it anyway?
(caveats about DOS attacks, existing frameworks and the like assumed)

>> The "heavy object sharing" lends itself really well to XSLT processors
>> or DOM objects that don't change, load once and re-use over and over.
>> This can really be crucial with XML processing, as XSLT transformers
>> tend to be kind of expensive to create.
>>
>
>True, but if you really have to, there are ways around it in PHP. But
>if you really want speed in processing, I suggest you implement it in
>C/C++. That is much faster.

C/C++ will always be faster than perl. (but you could just as well say
that if you need it fast, you should write it in assembly)

One reason for doing it in perl (or PHP) is that you don't need to compile
it for the platform.

Being able to store a tree in memory (with perl mod_perl/FCGI) is a balance
between cross-platform and performance. An option you don't really have
with PHP. (and actually, don't have with perl either, unless FCGI or mod_perl
is available)

Shared heavy objects are a significant issue with XSLT transformations.

>OTOH, perl is older and therefore more stable and mature. Newer is not
>always better. Each language needs to be evaluated in the context it
>will be used. A language which fits well into one project may not fit
>well into another.

In the context of XML and databases, I think perl is the winner. In the context
of popularity contests and quick projects, PHP is the winner.

Popularity is significant if you need to tie in with other products, as they
will most likely be PHP.

Jamie
--
http://www.geniegate.com Custom web programming
Perl * Java * UNIX User Management Solutions

[Back to original message]