From uhog.mit.edu!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!csnews!mox.perl.com!tchrist 27 Mar 1996 20:37:09 GMT Path: uhog.mit.edu!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!csnews!mox.perl.com!tchrist From: Tom Christiansen Newsgroups: comp.lang.perl.misc,comp.infosystems.www.authoring.cgi Subject: Re: What are my CGI language alternatives? Date: 27 Mar 1996 20:37:09 GMT Organization: Perl Consulting and Training Lines: 261 Message-ID: <4jc8tl$mfr@csnews.cs.colorado.edu> References: <4j9rfs$704@lal.interserv.net> Reply-To: tchrist@mox.perl.com (Tom Christiansen) NNTP-Posting-Host: perl.com Originator: tchrist@mox.perl.com Xref: uhog.mit.edu comp.lang.perl.misc:15158 comp.infosystems.www.authoring.cgi:13368 [courtesy cc of this posting sent to cited author via email] In comp.infosystems.www.authoring.cgi, Jeff Crist (whose middle initial is probably H in honor of Easter) scrawled the following: >I have been using Perl for my CGI scripts. My test server is >Windows NT, but my actual web site is running on UNIX. >Perl scripts really don't seem to be a great choice from >a performance standpoint. Are you sure? In what way? Too big? Too slow? Some programming techniques are more expensive that others, but Perl will nearly always waste memory to gain performance. Its footprint is largish, but you probably have more than one Perl program running on your system, so it's resident anyway, which means this isn't so big a problem. On the other hand, a few few memory and speed improvement have been made lately, so it's best to get the current source [URL#0], or at least check the release notes [URL#1]. [See attached URL index for various interesting bits cited in this posting.] I would say to analyse what in your program is slow or big, and see whether you can tune that up. Have you used a profiler? [URL#2] Rarely can I not get a text-based Perl program to within e times C's speed. Getting the algorithm right, however, isn't always obvious. Perl does make it easy for the programmer to do whatever they feel like despsite the consequences. If all else fails, you might do well to consider whether certain parts or even all of your application should be in C, heretical though this notion might initially appear. Some programs greatly benefit from a mixed language approach. For example, the current version of the vi editor from Berkeley contains an embedded Perl interpreter [URL#17]. A good general rule of thumb is to do as much as you can at as high a level as you can. For example, you might well choose to do whatever you *reasonably* can in the standard shell (Bourne, not Korn). If and when that's not fast or flexible enough, hand-tune for that part and so do the more critical bits in Perl. Or do whatever you *reasonably* can in Perl. If and when that's not fast or flexible enough, hand-tune for that part and so do the more critical bits in C. Or do whatever you *reasonably* can in C (ANSI C if possible, but not to the exclusion of compatibility with traditional K&R C). If and when that's not fast or flexible enough, hand-tune for that part and so do the more critical bits in assembly. Or do whatever you *reasonably* can in assembly. If and when that's not fast or flexible enough, hand-tune for that part and so do the more critical bits in handwritten microcode in firmware. If and when that's not fast or flexible enough, break down and etch in into silicon. It all just depends on what you're optmizing for. For example, a totally hand-written relational database in pure Perl isn't particularly parsimonious in its memory consumption: read, it's darned big. I know this from direct experience. :-( So maybe that part should be relegated to a disk-based scheme (maybe Berkeley DB or GDBM) instead of an in-core one. [URL#4] Or maybe it's time for a "real" database, probably an SQL-based one. Certainly Perl interfaces to these beasts exist, but you still have to fork over bucks for most of them. One you don't have to pay through the nose for, however is minisql, which also has a Perl interface. [URL#5] Maybe instead you find that there are a few routines that are just too slow in Perl. Is it Perl's fault, or yours? Can you reorganize your algorithm, Or is it inherent in the language? Could you use the XS (external subroutine) approach to link in some dedicated C routines that do the low-level stuff. [URL#7] For example, I once found myself needing to encode some extra integer data in 7-bit ascii, so stole the 8th bit for this purpose. While I could have done so in pure Perl, the routines had to run many, many times, so I ended up cheating a bit and using a wee bit of C to do this: void encode(char *string, int value) { char *s; int bit; s = string; *s++ |= 0200; for ( bit = 0; bit < MAXBITS; bit++, s++ ) { if ( value & (1 << bit) ) { *s |= 0200; } } } int decode(char *string) { int encode = 0; int bit; char *s; for (s = string; *s && !(*s & 0200); s++) /* VOID */; for (bit = 0; *s && bit < MAXBITS; s++, bit++) { if (*s & 0200) { *s &= 0177; encode += (1 << bit); } } return encode; } Those two functions are trivial to link into Perl using xsubpp and friends. [URL#7] Another possibility is that you're just being bombarded with CGI requests. Imagine getting 100,000 hits on the CGI stuff per day. That would mean that you'd have to start up more than one per second, and it's possible that just startup time would begin to dominate, especially if the CGI program is "big". You might want to consider moving the main CGI processing into a resident server whom you'd then communicate with over a low-overhead Unix-domain socket started from a small CGI front-end. You'd need to read up on IPC for that [URL#8]. This is the approach I've used for some of my larger web applications: just daemonize them. >Others have recommended that I use C++ instead. However I do not know >C++, only Pascal, Perl and Basic. I am wondering what are my other >options for a COMPILED CGI compatible programming language other than C++, >that are pretty easy to pick up and use, like Perl? Others' opinions shall surely vary, but I for one would try to stear my way clear of C++ -- it's a large and confusing creature. Writing in ANSI C would usually be easier. However, a case where it would be better to use C++ is if you have a great library that makes your particular application easier. Of course, you can say as much for any language, and certainly C has immensely fewer gotchas. If you'd really and truly like to go the C route, then you might look into Tom Boutell's cgic library [URL#6]. Tom is a pretty interesting fellow [URL#15], and no, I'm not talkin about myself. :-) I've not used his library myself -- I just use the Perl CGI modules [URL#16], but given his skill and background, it's probably pretty nifty. He even wrote a Perl-based MUD, so he must be cool! :-) [URL#13] Useless Net Personality Geotrivia: Like Jeff Christ, the other Tom even lives in Seattle, Boulder's (my town) sister city. It's our sister city in that I'd swear that it gets rain every day that we get sun and vice versa (~300 days of sunshine for Boulder, the reverse for Seattle :-). Both are very near to or in the mountains. Both are far more highly connected to the Internet than is normal. I'd also swear both cities drink more espresso and microbrews than the the rest of the country put together. Plus both cities seem to consume fewer hamburgers than tofu burgers and execute cigarette smokers upon sight (or sometimes just upon their smell :-). [URL#19] Anyway, if you already know Perl, C is a lot easier than if you're starting from scratch -- and vice versa -- but it's still no piece of cake. You see, C is actually a good bit harder to use than Perl or BASIC. That's because it's not a high-level language. It's a high-level *assembly* language, but a low-level (or perhaps mid-level) language all over. You have waste a lot of your life with fastidious details like memory management, strong typing, and bytewise string access. Libraries, of course, can help this, but no universal libraries exist that address all of it. That's why people use high-level languages, whether it be awk, Perl, Python, TCL, BASIC, Lisp, Scheme, Icon, or something else of their own making. One further note speedwise: a Perl (to C) compiler is well under construction. It's being written by Malcolm Beattie [URL#3], our official Perl Trailblazer.:-) I predict production quality sometimes this summer (for various values of summer). So it would seem that it's just a small matter of time before we no longer have the "oh, it's only byte-compiled, not native-compiled" complaint. >I have heard of something called Python but I don;t know anything about >it. I am also wondering if I am proficient in Perl, than is it pretty >easy to switch over C++? Python [URL#9] is -- like Perl -- a high-level, byte-compiled, interpreted language. Its design is arguably (but please let's not argue) somewhat cleaner than Perl's in certain respects, but at the cost of certain other compromises of utility. Still, if you are comfortable with Pascal, you might well enjoy Python: unlike Perl, it owes more to Modula and ABC than it does to C and Unix. Still, it's not everyone's cup of tea for various reasons [URL#11]. It is weaker in the string-manipulation arena than Perl is as you will be able to see in Jak Kirman's extensive Perl-Python Phrasebook [URL#12], which is based on my own Perl Data Structures Cookbook [URL#14]. On the other hand, Python may well be stronger than Perl in its object technology. Of course, Perl's OO stuff is quite easy to use [URL#18]. For more information on the Perl world, don't forget to keep up with the Perl homepage [URL#11]. Hope all this helps somehow. --tom ===================== URL Index for this Posting =================== [0] Current Perl Source (v5.002 production) http://www.perl.com/CPAN/src/5.0/perl5.002.tar.gz [1] Perl 5.002 Release notes http://www.perl.com/perl/info/release_5.002.html [2] Perl Profiler http://www.perl.com/cgi-bin/cpan_mod?module=Devel::Dprof [3] Malcolm Beattie's Home Page (perl-to-C compiler, etc) http://sable.ox.ac.uk/~mbeattie/perl.html [4] Berkeley DB Code http://www.perl.com/CPAN/src/misc/db.1.85.tar.gz [5] Perl Interface to minisql http://www.perl.com/cgi-bin/cpan_mod?module=Msql [6] Thomas Boutell's cgic library http://www.boutell.com/cgic/ [7] Perl XS Tutorial http://www.perl.com/perl/manual/perlxstut.html http://www.perl.com/perl/manual/perlxs.html [8] Perl IPC Tutorial http://www.perl.com/perl/manual/perlipc.html http://www.perl.com/perl/everything_to_know/ipc/ [9] Python Language Home Page http://www.python.org/ [10] Perl Advocacy Page http://www.perl.com/perl/versus/index.html [11] Perl Language Home Page http://perl.com/perl/ [12] Python/Perl Phrasebook http://maigret.cog.brown.edu/jak/cookbook.html [13] Perl MUD http://www.boutell.com/perlmud/ [14] Perl Data Structures Bookbook http://www.perl.com/perl/manual/perldsc.html http://www.perl.com/perl/manual/perllol.html http://www.perl.com/perl/everything_to_know/pdsc/ [15] Tom Boutell's Home Page http://www.boutell.com/ [16] Perl WWW && CGI Software http://www.perl.com/perl/info/cool_modules.html#WWW [17] Berkeley vi editor with Perl extensions ftp://ftp.cs.berkeley.edu/ucb/4bsd/nvi.ALPHA.1.57.tar.gz ftp://bostic.com/pub/nvi.ALPHA.1.57.tar.gz [18] Easy Object Intro for Perl http://www.perl.com/perl/everything_to_know/easy_objects.html [19] Boulder Colorado Information http://bcn.boulder.co.us/ -- Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com English is a 5-tuple ... --dmr