Date: Thu, 18 Mar 1999 11:37:12 +0100 From: Philippe Regnauld <none@regnauld--deepo.prosa.dk.lh.bsd-dk.dk> To: bsd-dk@hotel.prosa.dk Subject: Re: FreeBSD og danske tegn
Lasse Hillerøe Petersen writes:
> >
> > 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.
No, of course not! Well, some say that line noise is indistinguishable
from Perl code, that Perl is a write-only language, etc... :-)
The problem is that it's compile time -- thank God at least it's not
interpreted! But like all run-time compilation _environments_
(you can compile Perl and be done once and for all), you have
to include compile time in the exec time for all practical
purposes.
> > 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".
Of course it is! But you're talking for a specific case: a mostly
single user workstation, with loads of CPU and RAM -- the thing is,
too many people only learn the extremes, and one end of the
scale, you have people doing tight C or ASM coding with fascist memory
allocation (let's not even mention the COBOLites who coded years on
two numbers...), and the other end, you have those who always consider
that the target machine will be a single user machine with lots of
memory.
My personal workstation has 128 MB of RAM -- I was happy with 64 MB,
except that I chose to run KDE instead of FVWM (personal choice), but the extra
RAM is there for Netscape 4.5 (when Lynx doesn't cut it).
Netscape is a typical example of bloatware, I mean, it's _big_,
and it's not a static binary!
Memory is cheap, code is reentrant, multi user's efficient on
UNIX -- yes, but is that _always_ the case ?
I just think it's best to be conservative around memory in general,
because too many single programs running on one system are made
by people who thought they'd be the only ones running on that system :-)
> 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.
Compared to Java, anything holds a good position :-)
As for the startup time being negligible... Yes, if you start it once.
If you have 50 users (not much) logging in and out reading their mail
online, you do NOT want the mail reader to be in Perl!
hotel.prosa.dk, our member-pages machine, has shell accounts and Pine
to read mail. It works, and I'm happy it does, because I can't
go out and replace that machine for the moment: it's a 486-33 with
16 MB of RAM, and it holds well -- what DOES bring it to its knees
are the SSI stuff written in Perl (bad idea): there would be a good
idea to use mod_perl. But for invididual users, in their environments,
spawning Perl stuff all the time ?
Next thing we're going to hear is "Perl in the kernel".
Or worse: /kernel.pl :-)
This is less of a joke that it sounds -- there's already
filesystem modules available... written in Perl.
> 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.
Also a special case: you can write Perl really fast, and you said it,
it suits your needs -- prototyping, UIs, etc... no problem -- and
a mail reader would probably be a good idea -- but typically what
happens when people have to run CPU intensive Perl code often/many times
a day, they typically end up rewriting it in C.
(log analyzers are an example).
> decode encoded fields. I say this because I am so amazed every time, of how
> powerful and expressive Perl is.
No news there -- Perl is a blessing for those things.
> 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.)
Of course -- it's just that there's an extra "tap-your-fingers while it
loads" delay every time you exec the damn thing.
After that it flies :-)
> > 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!)
Ok! See, you just used a global statement! Limit the scope
of your opinions to that of the functions they belong to :-))))
You should try mutt :-P
> 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.
Hmm.. I used Elm for years. I moved to Mutt because it looked like Elm.
I only switched for one reason: threads. It threads discussions
by Message-Id as well as Subject. That's very important for mailing
lists. The other reason (came after) ? Completely redefinable behavior,
no mouse, and I've never lost a mail with it (v.0.88e).
> For
> me, this would be impossible if I had to do it in C. With Perl, at least I
> have a chance.
Ok, thanks for the clarification!
--
-[ Philippe Regnauld / Sysadmin ]-
This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:00 CET