A small yet niggling pet peeve of mine for many few years now, even though I rarely use perl these days, is the prevailing wisdom among experienced perl users that modules are the way to go whenever possible.
This is completely untrue in many circumstances and is, IMO, one of the reasons that perl has been replaced by PHP as the de facto web language.
I'll use an example from my own experience... Once upon a time there was a popular, and professionally written, perl script collection that happened to run a large number of sites I did contract work for.
These sites generally made a lot of money and had a lot of traffic. In addition the work being done by the script was unusually (and necessarily) resource intensive. As a result they tended to bring servers to their knees.
For quite a while I assumed that this was a natural limit, that it was just all the hardware could handle. I found a couple of areas to optimize but, largely, the scripts seemed very efficient.
Then one day, at a site which I owned and could therefore tinker with freely, I was trying to squeeze some extra performance out of a specialized area of these scripts. I decided to try dropping the modules, the most important one being the well loved CGI perl module.
After replacing the module with my own functions the result was immediate tripling of performance. Suddenly an overloaded server was no longer overloaded.
Just like that I had saved $1000's of dollars in new hardware infrastructure.
I have since seen similar issues on popular and successful websites that were written in perl. In each case they would be running on a server farm when they really should have needed only a few (and in some cases just one) server.
The overhead of loading a module that contains endless lines of unneeded code kills high load applications. Or so I assume.
While at the same time a PHP script written to do the same thing would use built in C++ functions and therefore completely avoid the issue.
Sure perl modules are great for little apps on little sites where performance is never going to be an issue, but on a site where performance can mean the difference between 4 and 5 figures monthly in hardware costs they are a huge mistake.
And yet 9 out of 10 perl experts will tell you differently with a straight face. :-)
go mod_perl
And lose the ability to distribute the application.
you'll love the speed
Why when I can use PHP with the everyday stuff built in and pre-compiled? Even faster execution, lower development time.
The only thing I use perl for these days is file access and system utilities since it gets better permissions by default on most server setups.
Not trying to start a PHP versus Perl thread though. I'm still fond of perl, I miss the shorthand :-)
modules you use can be loaded at server startup
Which is to say, load a lot of code you will never use into memory.
I'd rather cache database queries, etc. in those blocks thanks!
I thought you were talking about heavy traffic websites -- they won't mind using mod_perl, at least I never encountered that. Just regular hosting requires CGI (allthough: just use a generic interface and your app will run just fine on both).
>>Why when I can use PHP with the everyday stuff built in and pre-compiled? Even faster execution, lower development time.
I don't know about development time, guess that's an individual thing. I'm pretty sure though that mod_perl still beats php in speed, once it's loaded (e.g. if you don't load your handlers at startup, the first request might take a second).
plus, and that's the real big thing for me: controlling whatever you want to, not just the ResponsePhase in the request cycle of apache.
>>Which is to say, load a lot of code you will never use into memory.
hey, you were the one talking about php ;)
basically, that's what php does. afair, it has like 3000 built in functions. and, in a sane shared hosting environment, you'll most likely lose php's speed, since there are very few adventure loving admins that run mod_php on a server with alien scripts...
Edit: just to get back on topic - you're right. and nobody would argue against you, that's why there are many lightweight versions of the standard heavy modules around, aimed at those who need the most performance.
[perldoc.perl.org...]
If they ever get into the desirable position of having so much traffic to a site they need to squeeze out all the performance they can get, then they will have to invest accordingly, in hardware, software, and everything in between. That is a step up most people will never face.
the people asking questions generally have little or no idea of what they are doing or getting themselves into. In that case using a module is a very good idea.
You're right and it's understandable.
Nevertheless what it really translates to is an excuse. It's the act of passing on poor programming practices for convenience sake.
Your average person is better off using the CGI module (and other modules).
It's not just your average person. Many professional programmers and gurus routinely use the CGI module (et al). As they will very loudly tell you :-)
If they ever get into the desirable position of having so much traffic to a site they need to squeeze out all the performance they can get, then they will have to invest accordingly
Go back and rewrite the entire back end? That rarely happens, instead you end up with more and more hardware.
That is a step up most people will never face.
I suppose it's a matter of perspective.
In my experience websites with millions of daily requests are far from rare. And if your application is high load (lots of data crunching, database queries, external requests, etc...) you really only need to get into the 6 figure requests range before performance becomes an issue.
Also consider that for a small time webmaster the difference between one server and a database + web server setup is a big deal. Especially when, in most cases, the realistic move is from one to three servers.
The bottom line is that if you're coding for the web, efficiency is important from the very beginning. It's not realistic to expect to be able to go back and fix your efficiency mistakes later when the application becomes successful.
I know ... but still, give mod_perl a try.
I've used it in the past. I'm definitely not saying there's anything wrong with it.
The bottom line is that if you're coding for the web, efficiency is important from the very beginning. It's not realistic to expect to be able to go back and fix your efficiency mistakes later when the application becomes successful.
Nearly every major website that has been around for a number of years has done just that several times over. I remember when ebay used perl and had one sever. There is no way the founder (his name escapes me now) could had predicted the kind of traffic ebay was going to generate from the very beginning. Many popular sites started out on a shoe-string budget and had to do total overhauls, some did them a number of times and I assume they continue to do them.
Is there any good reason not to write efficient code from the beginning?
These days pretty much everyone launches websites with the intent of getting large quantities of traffic. And the total net population is large enough to make that a reasonable goal.
I'm working on a guys website right now, started on a shoe-string, he is now purchasing his first server and hiring people to help him now that he is generating income and traffic. Thats really what is so cool about an internet business, you can literally start it with a few dollars and expand as your needs increase. There is really no need to start with all the bells and whistles and blow a wad of cash unless you have those resources and can afford to lose them in case the website fails to generate enough revenue.
But that doesn't have much to do with coding for the web.
you will most likely use whatever is avaialable at low or no cost
Efficient code is free.
