On Tue, Aug 26, 2003 at 07:53:34PM -0500, Ron Johnson wrote: > On Tue, 2003-08-26 at 19:35, Britton wrote: > > On Tue, 26 Aug 2003, Bijan Soleymani wrote: > > > > > On Tue, Aug 26, 2003 at 11:25:55AM -0500, Ron Johnson wrote: > [snip] > > This just isn't true. Perl at least is brought to its knees by a variety > > of problems that C has no trouble with whatsoever. I've had simple > > pixel-crawling image processing algorithms take a day to run in Perl, when > > I rewrote in C about 30 seconds. And that's with PDL (admittedly PDL call > > overhead was I think the major thing slowing perl down, but that's hardly > > reassuring). The scripting languages just aren't anywhere near as fast as > > the older, simpler, compiled ones. Its not that I don't still write first > > drafts of many codes in perl, its just that now I budget time to rewrite > > them in C if I need to (its still usually faster overall to prototype > > first in perl, even if you know you are doomed speed-wise). I don't know > > if perl and cobol have the same relationship, or if there are common > > business tasks that still need the speed, but it seems like a definite > > possibility. > > You might want to try Python as a prototyping, and even implementation, > language. It has many graphics libraries that are coded in C for > speed. Thus, you get the benefits of a VHLL plus a LLL (low level > language) when speed is needed.
Is there any reason why any of these complex scripting languages have to be interpreted, as opposed to compiled? Some quite complex packages are around which have been written in such languages; Perl seems to be both common and expensive. It would appear that the inefficiency of Perl is the reason why my print server (a 600MHz box) takes forever to render pages for my Canon LBP-4, which uses a foomatic driver, compared to the time it takes for a printer that speaks straight HewlettPackardish and can use one of cups's built-in drivers. Similarly, spamassassin seems to be notorious for chewing up lots of resources. To me, it seems that the obvious solution is to run the script through a Perl compiler, and produce a binary executable that should execute at the same order of speed as any other compiled HLL code. Why is this not done? Is it simply that nobody's bothered to write a Perl compiler, or is there some infelicity in the design of Perl that makes it impractical? -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
pgp00000.pgp
Description: PGP signature
