Bob Tanner <tanner at real-time.com> writes: > Quoting David Dyer-Bennet (dd-b at dd-b.net): > > I note you talk almost entirely about memory use here; and obviously > > that's a strong reason you or anybody might be driven off Perl on a > > heavily-used dynamic site. Any feeling for other performance > > measures? > > Ok, soapbox time, this is not flamebait. It will probably show my ignorance on > how far perl has come. Hopefully some perl mongers are here so they can set me > right. > > When I was "into" perl, it was ver 4.x, so there probably lots of things that I > _think_ perl can't do, or does badly that are now "fixed" in 5.5 or 5.6. > > Servlets are faster, especially when dealing with large database queries. In > particular, objects that deal with lookup tables. Because servlets are > persistent, you can at start up time perform one-time initialization routines. > For instance, you DB table of the Countries. In this table is the full country > name (United States of America), the ISO designation (US), optional short name > (USA) and an application specific number. At start-up of the servlet container > you can hit the DB and put resultSet into an efficient lookup object like a > red-black tree or something a little more flexible like a hashtable. > > This is done just once, at boot time. Now access to this object are all done > quickly from memory, because the servlet is persistent. Using perl, you have to > hit the DB each time for this result (perl monger flame?). I know php has > something similar, so sort of cache thing. Cold fusion caches those queries automatically, I believe. > Java has native thread support with priorities. So servlets can > "perform" nicely with each other more easily. One particular > application I wrote has a "long" (60-120 seconds) processing > cycle. The information is not time sensitive. So putting this > request into a very low priority thread helps servlets scale. I > don't think perl can do this (perl monger flame?), so ever perl cgi > is give same priority. The perl CGI could set itself to a lower priority also ("nice"). > Servlets perform better with legacy systems and non-Unix based > systems (ok, perl mongers are going to have to flame me on > this). These are all things I could do under Java (easily) that I > could not do under perl or was difficult to do under perl. Perl and CGI in general have problems on Microsoft systems, where process startup is expensive rather than cheap, so servlets should perform better in that kind of environment. Is there anything important to the web (server side) other than NT and Unix, though? > Talking to MS SQL Server is no different then talking to MySQL or > Postgres. It's all JDBC. Perl does this fine through DBI. Another problem with CGI in general that you didn't mention, though, is that for some database servers it's actually expensive to establish the connection, and with a persistent system like servlets, php, or Cold Fusion those connections can be pooled / reused. (Mainframe DB2 through a middleware layer and ODBC, for example; sheesh!) A lot of the specific modules (capabilities) you mention are things that there's a perl object for these days. But any way you look at it, somebody else having already done the work is a big win! -- David Dyer-Bennet / Welcome to the future! / dd-b at dd-b.net SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/