perl-modperl-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sbek...@hyperreal.org
Subject cvs commit: modperl-site perl_myth.html perl_myth.pod
Date Thu, 05 Aug 1999 06:24:27 GMT
sbekman     99/08/04 23:24:26

  Modified:    .        perl_myth.html perl_myth.pod
  Log:
  updated the perl_myth.pod
  
  Revision  Changes    Path
  1.2       +81 -40    modperl-site/perl_myth.html
  
  Index: perl_myth.html
  ===================================================================
  RCS file: /export/home/cvs/modperl-site/perl_myth.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- perl_myth.html	1999/08/03 06:49:24	1.1
  +++ perl_myth.html	1999/08/05 06:24:25	1.2
  @@ -1,7 +1,7 @@
   <HTML>
   <HEAD>
   <TITLE>Popular Perl Complaints and Myths</TITLE>
  -<LINK REV="made" HREF="mailto:ianmacd@caliban.xs4all.nl">
  +<LINK REV="made" HREF="mailto:root@porky.devel.redhat.com">
   </HEAD>
   
   <BODY>
  @@ -11,9 +11,11 @@
   <UL>
   
   	<LI><A HREF="#Popular_Perl_Complaints_and_Myth">Popular Perl Complaints and
Myths</A>
  +	<LI><A HREF="#Abbreviations">Abbreviations</A>
   	<UL>
   
   		<LI><A HREF="#Interpreted_vs_Compiled">Interpreted vs. Compiled</A>
  +		<LI><A HREF="#Interpreted_vs_Compiled_More_G">Interpreted vs. Compiled (More
Gory Details)</A>
   		<LI><A HREF="#Perl_is_overly_memory_intensive_">Perl is overly memory intensive
making it unscalable</A>
   		<LI><A HREF="#Not_enough_support_or_tools_to_">Not enough support, or tools
to develop with Perl. (Myth)</A>
   		<LI><A HREF="#If_Perl_scales_so_well_how_come">If Perl scales so well, how
come no large sites use it? (myth)</A>
  @@ -39,16 +41,29 @@
   <H1><A NAME="Popular_Perl_Complaints_and_Myth">Popular Perl Complaints and
Myths</A></H1>
   <P>
   <HR>
  +<H1><A NAME="Abbreviations">Abbreviations</A></H1>
  +<UL>
  +<LI>
  +<P>
  +M = Misconception or Myth
  +
  +<LI>
  +<P>
  +R = Response
  +
  +</UL>
  +<P>
  +<HR>
   <H2><A NAME="Interpreted_vs_Compiled">Interpreted vs. Compiled</A></H2>
   <DL>
  -<DT><STRONG><A NAME="item_Q">Q:</A></STRONG><DD>
  +<DT><STRONG><A NAME="item_M">M:</A></STRONG><DD>
   <P>
   Each dynamic perl page hit needs to load the Perl interpreter and compile
   the script, then run it each time a dynamic web page is hit. This
   dramatically decreases performance as well as makes Perl an unscalable
   model since so much overhead is required to search each page.
   
  -<DT><STRONG><A NAME="item_A">A:</A></STRONG><DD>
  +<DT><STRONG><A NAME="item_R">R:</A></STRONG><DD>
   <P>
   This myth was true years ago before the advent of mod_perl. mod_perl loads
   the interpreter once into memory and never needs to load it again. Each
  @@ -56,32 +71,72 @@
   memory and used each time the program is run. In this way there is no extra
   overhead when hitting a mod_perl page.
   
  +<H2><A NAME="Interpreted_vs_Compiled_More_G">Interpreted vs. Compiled (More
Gory Details)</A></H2>
  +<LI>
  +<P>
  +Compiled code always has the potential to be faster than interpreted code.
  +Ultimately, all interpreted code needs to eventually be converted to native
  +instructions at some point, and this is invariably has to be done by a
  +compiled application. That said, an interpreted language CAN be faster than
  +a comprable native application in certain situations, given certain, common
  +programming practices. For example, the allocation and de-allocation of
  +memory can be a relatively expensive process in a tightly scoped compiled
  +language, wheras interpreted languages typically use garbage collectors
  +which don't need to do expensive deallocation in a tight loop, instead
  +waiting until additional memory is absolutely necessary, or for a less
  +computationally intensive period. Of course, using a garbage collector in C
  +would eliminate this edge in this situation, but where using garbage
  +collectors in C is uncommon, Perl and most other interpreted languages have
  +built-in garbage collectors. It is also important to point out that few
  +people use the full potential of their modern CPU with a single
  +application. Modern CPUs are not only more than fast enough to run
  +interpreted code, many processors include instruction sets designed to
  +increase the performance of interpreted code.
  +
   </DL>
   <P>
   <HR>
   <H2><A NAME="Perl_is_overly_memory_intensive_">Perl is overly memory intensive
making it unscalable</A></H2>
   <DL>
  -<DT><STRONG>Q:</STRONG><DD>
  +<DT><STRONG>M:</STRONG><DD>
   <P>
   Each child process needs the Perl interpreter and all code in memory. Even
   with mod_perl httpd processes tend to be overly large, slowing performance,
   and requiring much more hardware.
   
  -<DT><STRONG>A:</STRONG><DD>
  +<DT><STRONG>R:</STRONG><DD>
   <P>
   In mod_perl the interpreter is loaded into the parent process and shared
   between the children. Also, when scripts are loaded into the parent and the
   parent forks a child httpd process, that child shares those scripts with
   the parent. So while the child may take 6MB of memory, 5MB of that might be
   shared meaning it only really uses 1MB per child. Even 5 MB of memory per
  -child is not uncommon for most web applications on other languages.
  +child is not uncommon for most web applications on other languages. Also,
  +most modern operating systems support the concept of shared libraries. Perl
  +can be compiled as a shared library, enabling the bulk of the perl
  +interpreter to be shared between processes. Some executable formats on some
  +platforms (I believe ELF is one such format) are able to share entire
  +executable TEXT segments between unrelated processes.
   
  -</DL>
   <P>
  -<HR>
  +More Tuning Advice:
  +
  +<UL>
  +<LI>
  +<P>
  +<STRONG>Vivek Khera's mod_perl performance tuning guide</STRONG>( <A
  +HREF="http://perl.apache.org/tuning/">http://perl.apache.org/tuning/</A> )
  +
  +<LI>
  +<P>
  +<STRONG>Stas Bekman's Performance Guide</STRONG>( <A
  +HREF="http://perl.apache.org/guide/performance.html">http://perl.apache.org/guide/performance.html</A>
  +)
  +
  +</UL>
   <H2><A NAME="Not_enough_support_or_tools_to_">Not enough support, or tools
to develop with Perl. (Myth)</A></H2>
   <DL>
  -<DT><STRONG>A:</STRONG><DD>
  +<DT><STRONG>M:</STRONG><DD>
   <P>
   Of all web applications and languages, Perl arguable has the most support
   and tools. <STRONG>CPAN</STRONG> is a central repository of Perl modules which
are freely downloadable and
  @@ -89,14 +144,12 @@
   building web apps in Perl much easier. There are also countless mailing
   lists of extremely responsive Perl experts who usually respond to questions
   within an hour. There are also a number of Perl development environments to
  -make building Perl Web applications easier. Just to name a few, there is <CODE>Perl::ASP</CODE>,
<CODE>Mason</CODE>, <CODE>embPerl</CODE>, <CODE>ePerl</CODE>,
etc...
  +make building Perl Web applications easier. Just to name a few, there is <CODE>Apache::ASP</CODE>,
<CODE>Mason</CODE>, <CODE>embPerl</CODE>, <CODE>ePerl</CODE>,
etc...
   
   </DL>
  -<P>
  -<HR>
   <H2><A NAME="If_Perl_scales_so_well_how_come">If Perl scales so well, how come
no large sites use it? (myth)</A></H2>
   <DL>
  -<DT><STRONG>A:</STRONG><DD>
  +<DT><STRONG>R:</STRONG><DD>
   <P>
   Actually, many large sites DO use Perl for the bulk of their web
   applications. Here are some, just as an example: <STRONG>e-Toys</STRONG>,
  @@ -108,11 +161,9 @@
   ).
   
   </DL>
  -<P>
  -<HR>
   <H2><A NAME="Perl_even_with_mod_perl_is_alwa">Perl even with mod_perl, is always
slower then C.</A></H2>
   <DL>
  -<DT><STRONG>Q:</STRONG><DD>
  +<DT><STRONG>M:</STRONG><DD>
   <P>
   There are two issues to consider here. First of all, many times a web
   application written in Perl <STRONG>CAN be faster</STRONG> than C thanks to
the low level optimizations in the Perl compiler. In other
  @@ -126,16 +177,14 @@
   be a huge competitive advantage.
   
   </DL>
  -<P>
  -<HR>
   <H2><A NAME="Java_does_away_with_the_need_for">Java does away with the need
for Perl.</A></H2>
   <DL>
  -<DT><STRONG>Q:</STRONG><DD>
  +<DT><STRONG>M:</STRONG><DD>
   <P>
   Perl had its place in the past, but now there's Java and Java will kill
   Perl.
   
  -<DT><STRONG>A:</STRONG><DD>
  +<DT><STRONG>R:</STRONG><DD>
   <P>
   Java and Perl are actually more complimentary languages then competitive.
   Its widely accepted that server side Java solutions such as <CODE>JServ</CODE>,
<CODE>JSP</CODE> and <CODE>JRUN</CODE>, are far slower then mod_perl
solutions (see next myth). Even so, Java is
  @@ -145,11 +194,9 @@
   made very powerful.
   
   </DL>
  -<P>
  -<HR>
   <H2><A NAME="Perl_can_t_create_advanced_clien">Perl can't create advanced client
side applications</A></H2>
   <DL>
  -<DT><STRONG>A:</STRONG><DD>
  +<DT><STRONG>R:</STRONG><DD>
   <P>
   True. There are some client side Perl solutions like PerlScript in MSIE
   5.0, but all client side Perl requires the user to have the Perl
  @@ -159,17 +206,15 @@
   programming language and Perl as the server side solution.
   
   </DL>
  -<P>
  -<HR>
   <H2><A NAME="ASP_makes_Perl_obsolete_as_a_web">ASP makes Perl obsolete as a
web programming language.</A></H2>
   <DL>
  -<DT><STRONG>Q:</STRONG><DD>
  +<DT><STRONG>M:</STRONG><DD>
   <P>
   With Perl you have to write individual programs for each set of pages. With
   ASP you can write simple code directly within HTML pages. ASP is the Perl
   killer.
   
  -<DT><STRONG>A:</STRONG><DD>
  +<DT><STRONG>R:</STRONG><DD>
   <P>
   There are many solutions which allow you to embed Perl in web pages just
   like ASP. In fact, you can actually use Perl IN ASP pages with PerlScript.
  @@ -180,11 +225,12 @@
   mod_perl is usually much faster then ASP, Perl has much more example code
   and full programs which are freely downloadable, and Perl is cross
   platform, able to run on Solaris, Linux, SCO, Digital Unix, Unix V, AIX,
  -OS2, VMS MacOS, Win95-98 and NT to name a few.
  +OS2, VMS MacOS, Win95-98 and NT to name a few. Also, Benchmarks show that
  +embedded Perl solutions outperform ASP/VB on IIS by several orders of
  +magnitude. Perl is a much easier language for some to learn, especially
  +those with a background in C or C++.
   
   </DL>
  -<P>
  -<HR>
   <H1><A NAME="CREDITS">CREDITS</A></H1>
   <P>
   Thanks to the mod_perl list for all of the good information and criticism.
  @@ -234,36 +280,31 @@
   <P>
   Finally, I'd like to thank Robert Santos &lt;<A
   HREF="mailto:robert@cnation.com">robert@cnation.com</A>&gt;, CyberNation's
  -lead Business Development guy for doubting me and inspiring this document.
  +lead Business Development guy for inspiring this document.
   
   </UL>
  -<P>
  -<HR>
   <H1><A NAME="AUTHOR">AUTHOR</A></H1>
   <P>
   Adam Pisoni
   
  -<P>
  -<HR>
   <H2><A NAME="Contact_info">Contact info</A></H2>
   <P>
   email: <A HREF="mailto:adam@cnation.com">adam@cnation.com</A>
   
   <P>
  -WWW: <A HREF="http://sm-pug.cnation.com">http://sm-pug.cnation.com</A>
  +WWW: <A HREF="http://sm.pm.org/">http://sm.pm.org/</A>
   
   <P>
   WWW: <A HREF="http://www.cnation.com">http://www.cnation.com</A>
   
  -<P>
  -<HR>
   <H1><A NAME="VERSION">VERSION</A></H1>
   <P>
  -Ver 1.0 
  +Ver 1.03 
   
   <P>
  -Tue Aug 3 06:26:36 IDT 1999
  +Tue Aug 4 9:41:00 PST 1999
   
  +</DL>
   </BODY>
   
   </HTML>
  
  
  
  1.2       +76 -21    modperl-site/perl_myth.pod
  
  Index: perl_myth.pod
  ===================================================================
  RCS file: /export/home/cvs/modperl-site/perl_myth.pod,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- perl_myth.pod	1999/08/03 06:49:24	1.1
  +++ perl_myth.pod	1999/08/05 06:24:25	1.2
  @@ -1,11 +1,24 @@
  -
   =head1 Popular Perl Complaints and Myths
   
  +=head1 Abbreviations
  +
  +=over 4
  +
  +=item *
  +
  +M = Misconception or Myth
  +
  +=item *
  +
  +R = Response
  +
  +=back
  +
   =head2 Interpreted vs. Compiled
   
   =over 4
   
  -=item Q:
  +=item M:
   
   Each dynamic perl page hit needs to load the Perl interpreter and
   compile the script, then run it each time a dynamic web page is hit.
  @@ -13,7 +26,7 @@
   unscalable model since so much overhead is required to search each
   page.
   
  -=item A:
  +=item R:
   
   This myth was true years ago before the advent of mod_perl.  mod_perl
   loads the interpreter once into memory and never needs to load it
  @@ -21,19 +34,44 @@
   is then kept into memory and used each time the program is run.  In
   this way there is no extra overhead when hitting a mod_perl page.
   
  +=head2 Interpreted vs. Compiled (More Gory Details)
  +
  +=item *
  +
  +Compiled code always has the potential to be faster than interpreted
  +code. Ultimately, all interpreted code needs to eventually be converted
  +to native instructions at some point, and this is invariably has to be
  +done by a compiled application.
  +  That said, an interpreted language CAN be faster than a comprable
  +native application in certain situations, given certain, common
  +programming practices. For example, the allocation and de-allocation of
  +memory can be a relatively expensive process in a tightly scoped
  +compiled language, wheras interpreted languages typically use garbage
  +collectors which don't need to do expensive deallocation in a tight
  +loop, instead waiting until additional memory is absolutely necessary,
  +or for a less computationally intensive period. Of course, using a
  +garbage collector in C would eliminate this edge in this situation, but
  +where using garbage collectors in C is uncommon, Perl and most other
  +interpreted languages have built-in garbage collectors.
  +  It is also important to point out that few people use the full
  +potential of their modern CPU with a single application. Modern CPUs are
  +not only more than fast enough to run interpreted code, many processors
  +include instruction sets designed to increase the performance of
  +interpreted code.
  +
   =back
   
   =head2 Perl is overly memory intensive making it unscalable
   
   =over 4
   
  -=item Q:
  +=item M:
   
   Each child process needs the Perl interpreter and all code in memory.
   Even with mod_perl httpd processes tend to be overly large, slowing
   performance, and requiring much more hardware.
   
  -=item A: 
  +=item R: 
   
   In mod_perl the interpreter is loaded into the parent process and
   shared between the children.  Also, when scripts are loaded into the
  @@ -42,14 +80,31 @@
   memory, 5MB of that might be shared meaning it only really uses 1MB
   per child.  Even 5 MB of memory per child is not uncommon for most web
   applications on other languages.
  +  Also, most modern operating systems support the concept of shared libraries. Perl
  +can be compiled as a shared library, enabling the bulk of the perl
  +interpreter to be shared between processes. Some executable formats on
  +some platforms (I believe ELF is one such format) are able to share
  +entire executable TEXT segments between unrelated processes.
   
  +=over 4
  +
  +More Tuning Advice:
  +
  +=item *
  +
  +B<Vivek Khera's mod_perl performance tuning guide>( http://perl.apache.org/tuning/
)
  +
  +=item *
  +
  +B<Stas Bekman's Performance Guide>( http://perl.apache.org/guide/performance.html
)
  +
   =back
   
   =head2 Not enough support, or tools to develop with Perl. (Myth)
   
   =over 4
   
  -=item A:
  +=item M:
   
   Of all web applications and languages, Perl arguable has the most
   support and tools. B<CPAN> is a central repository of Perl modules
  @@ -59,7 +114,7 @@
   responsive Perl experts who usually respond to questions within an
   hour.  There are also a number of Perl development environments to
   make building Perl Web applications easier.  Just to name a few, there
  -is C<Perl::ASP>, C<Mason>, C<embPerl>, C<ePerl>, etc...
  +is C<Apache::ASP>, C<Mason>, C<embPerl>, C<ePerl>, etc...
   
   =back
   
  @@ -67,7 +122,7 @@
   
   =over 4
   
  -=item A:
  +=item R:
   
   Actually, many large sites DO use Perl for the bulk of their web
   applications.  Here are some, just as an example: B<e-Toys>,
  @@ -83,7 +138,7 @@
   
   =over 4
   
  -=item Q:
  +=item M:
   
   There are two issues to consider here.  First of all, many times a web
   application written in Perl B<CAN be faster> than C thanks to the low
  @@ -103,12 +158,12 @@
   
   =over 4
   
  -=item Q:
  +=item M:
   
   Perl had its place in the past, but now there's Java and Java will
   kill Perl.
   
  -=item A:
  +=item R:
   
   Java and Perl are actually more complimentary languages then
   competitive.  Its widely accepted that server side Java solutions such
  @@ -125,7 +180,7 @@
   
   =over 4
   
  -=item A:
  +=item R:
   
   True.  There are some client side Perl solutions like PerlScript in
   MSIE 5.0, but all client side Perl requires the user to have the Perl
  @@ -140,13 +195,13 @@
   
   =over 4
   
  -=item Q: 
  +=item M: 
   
   With Perl you have to write individual programs for each set of pages.
   With ASP you can write simple code directly within HTML pages.  ASP is
   the Perl killer.
   
  -=item A:
  +=item R:
   
   There are many solutions which allow you to embed Perl in web pages
   just like ASP.  In fact, you can actually use Perl IN ASP pages with
  @@ -159,6 +214,9 @@
   programs which are freely downloadable, and Perl is cross platform,
   able to run on Solaris, Linux, SCO, Digital Unix, Unix V, AIX, OS2,
   VMS MacOS, Win95-98 and NT to name a few.
  +  Also, Benchmarks show that embedded Perl solutions outperform ASP/VB on IIS
  +by several orders of magnitude. Perl is a much easier language for some
  +to learn, especially those with a background in C or C++.
   
   =back
   
  @@ -203,9 +261,7 @@
   
   =item *
   
  -Finally, I'd like to thank Robert Santos <robert@cnation.com>,
  -CyberNation's lead Business Development guy for doubting me and
  -inspiring this document.
  +Finally, I'd like to thank Robert Santos <robert@cnation.com>, CyberNation's lead
Business Development guy for inspiring this document.
   
   =back
   
  @@ -217,15 +273,14 @@
   
   email: adam@cnation.com
   
  -WWW: http://sm-pug.cnation.com
  +WWW: http://sm.pm.org/
   
   WWW: http://www.cnation.com
   
   =head1 VERSION
   
  -Ver 1.0 
  +Ver 1.03 
   
  -Tue Aug  3 06:26:36 IDT 1999
  +Tue Aug  4 9:41:00 PST 1999
   
   =cut
  -
  
  
  

Mime
View raw message