Date: Thu, 18 Mar 1999 10:51:23 +0100 To: bsd-dk@hotel.prosa.dk From: Lasse Hillerøe Petersen <none@lassehp--imv.au.dk.lh.bsd-dk.dk> Subject: Re: FreeBSD og danske tegn
>Lasse Hillerøe Petersen writes:
>> > So you can use 25 MB of RAM, and 100% CPU for 1 minute to read
>> > a 3000 mail mailbox ?
>>
>> Now that's what I call an opinion. Different, I must say. Valid? I am not
>> so sure. A strong opinion - certainly. You have some hangup with Perl or
>> something?
>
> I write exclusively in Perl. I wrote firewall log analysis
> tools in Perl/Tk. EU.org, which I co administrate, runs the
> entire administration (front end + back end) in Perl. I love
> Perl, but to each tool its use.
>
> Perl's instantiation time is long enough that Apache has a
> module to keep it running in memory to avoid the overhead
> of fork+exec+parse. Perl is great for large scripting,
> automated tasks and prototyping, and some smaller application
> development.
I believe the problem is mainly the parse (and loading of modules). In any
case, this is a problem that has risen out of the current Perl
implementation's growth (with many, many modules, that take more and more
time to load), and I believe work is being done to reduce or eliminate it.
It is not an intrinsic problem with Perl, the language.
>
> It's perfectly reasonable to write an application like a
> mailreader in Perl -- after all, there are X Window mail
> readers written in tcl/tk :-)
>
> But don't expect great performance or low memory footprint :-)
I believe someone must have said: "memory is cheap".
As for performance: a mail reader is an interactive program, spending most
time waiting for the user to make a decision about what to do. The startup
time is also negligible, as the program would typically be running all the
time. Further, I have seen comparisons with C, C++ and Java, where Perl
holds a good position, especially compared to Java. Of course such
comparisons are not gospel, but I have had no performance problem with Perl
so far. And the speed with which a program can be written is far mor
important for me.
The other day, I wrote a program in 68 lines of Perl (with -w and use
strict; and a few comments!) that will parse an LDIF file, sort by an
arbitrary field, search for records using and/or combinations of multiple
pattern matches to an arbitrary selection of fields, and print a choice of
fields for each found record. The only module I used was MIME::Base64 to
decode encoded fields. I say this because I am so amazed every time, of how
powerful and expressive Perl is.
> Perl's optimization is targeted to "launch one, run long", with
> _extremely_ good optimization around regular expression
> (parsing, concatenation, and reduction). The syntax is extendable,
> the execution does runtime garbage collection -- all these things
> come at a price: longer first-run launch (OS caching helps a lot
> afterwards), and bigger memory footprint.
Currently true, but I expect this is something that will be fixed over
time. And as you say, the operations, once the program has launched, has
been parsed/compiled, and all modules have been loaded (and
parsed/compiled), the performance is quite good (as you have admitted in
another message.)
> Like I said, I like Perl, but I certainly don't grab numbers
> out of the air -- as for opinions, I wasn't the one
> to say that "all mail readers suck, I'll write my own in Perl".
I said that? Oh, indeed I did. Sorry, of course I should have said: "all
the mail readers I have seen so far (Eudora, Pegasus, Netscape,
OutlookExpress,ClarisEmailer,MailSmith, Mail, mailx -- no, I don't read
mail on Unix much!) haven't been my cup of tea. That's a much weaker
statement. However, reading mail is something we all do a lot, and
therefore everybody tends to have strong opinions about it, and dream of a
mailer with the perfect feature-set and built-in personalized workflow. For
me, this would be impossible if I had to do it in C. With Perl, at least I
have a chance.
-Lasse
This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:00 CET