FAQ sync

p4raw-id: //depot/perl@24024

1 files changed, 58 insertions, 58 deletions

diff --git a/pod/perlfaq3.pod b/pod/perlfaq3.pod
index 33675bfff3..7dede4c75d 100644
--- a/pod/perlfaq3.pod
+++ b/pod/perlfaq3.pod
@@ -1,6 +1,6 @@
 =head1 NAME
 
-perlfaq3 - Programming Tools ($Revision: 1.41 $, $Date: 2004/11/03 22:45:32 $)
+perlfaq3 - Programming Tools ($Revision: 1.46 $, $Date: 2005/02/13 02:36:09 $)
 
 =head1 DESCRIPTION
 
@@ -407,8 +407,8 @@ no 32k limit).
 
 =item Affrus
 
-is a full Perl development enivornment with full debugger support (
-http://www.latenightsw.com ).
+is a full Perl development enivornment with full debugger support 
+( http://www.latenightsw.com ).
 
 =item Alpha
 
@@ -649,23 +649,25 @@ everything works out right.
 
 =head2 How can I free an array or hash so my program shrinks?
 
-You usually can't. On most operating systems, memory
-allocated to a program can never be returned to the system.
-That's why long-running programs sometimes re-exec
-themselves. Some operating systems (notably, systems that
-use mmap(2) for allocating large chunks of memory) can
-reclaim memory that is no longer used, but on such systems,
-perl must be configured and compiled to use the OS's malloc,
-not perl's.
-
-However, judicious use of my() on your variables will help make sure
-that they go out of scope so that Perl can free up that space for
-use in other parts of your program.  A global variable, of course, never
-goes out of scope, so you can't get its space automatically reclaimed,
-although undef()ing and/or delete()ing it will achieve the same effect.
+(contributed by Michael Carman)
+
+You usually can't. Memory allocated to lexicals (i.e. my() variables)
+cannot be reclaimed or reused even if they go out of scope. It is
+reserved in case the variables come back into scope. Memory allocated
+to global variables can be reused (within your program) by using
+undef()ing and/or delete().
+
+On most operating systems, memory allocated to a program can never be
+returned to the system. That's why long-running programs sometimes re-
+exec themselves. Some operating systems (notably, systems that use
+mmap(2) for allocating large chunks of memory) can reclaim memory that
+is no longer used, but on such systems, perl must be configured and
+compiled to use the OS's malloc, not perl's.
+
 In general, memory allocation and de-allocation isn't something you can
-or should be worrying about much in Perl, but even this capability
-(preallocation of data types) is in the works.
+or should be worrying about much in Perl.
+
+See also "How can I make my Perl program take less memory?"
 
 =head2 How can I make my CGI script more efficient?
 
@@ -753,41 +755,40 @@ you want to be sure your license's wording will stand up in court.
 
 =head2 How can I compile my Perl program into byte code or C?
 
-Malcolm Beattie has written a multifunction backend compiler,
-available from CPAN, that can do both these things.  It is included
-in the perl5.005 release, but is still considered experimental.
-This means it's fun to play with if you're a programmer but not
-really for people looking for turn-key solutions.
-
-Merely compiling into C does not in and of itself guarantee that your
-code will run very much faster.  That's because except for lucky cases
-where a lot of native type inferencing is possible, the normal Perl
-run-time system is still present and so your program will take just as
-long to run and be just as big.  Most programs save little more than
-compilation time, leaving execution no more than 10-30% faster.  A few
-rare programs actually benefit significantly (even running several times
-faster), but this takes some tweaking of your code.
-
-You'll probably be astonished to learn that the current version of the
-compiler generates a compiled form of your script whose executable is
-just as big as the original perl executable, and then some.  That's
-because as currently written, all programs are prepared for a full
-eval() statement.  You can tremendously reduce this cost by building a
-shared I<libperl.so> library and linking against that.  See the
-F<INSTALL> podfile in the Perl source distribution for details.  If
-you link your main perl binary with this, it will make it minuscule.
-For example, on one author's system, F</usr/bin/perl> is only 11k in
-size!
-
-In general, the compiler will do nothing to make a Perl program smaller,
-faster, more portable, or more secure.  In fact, it can make your
-situation worse.  The executable will be bigger, your VM system may take
-longer to load the whole thing, the binary is fragile and hard to fix,
-and compilation never stopped software piracy in the form of crackers,
-viruses, or bootleggers.  The real advantage of the compiler is merely
-packaging, and once you see the size of what it makes (well, unless
-you use a shared I<libperl.so>), you'll probably want a complete
-Perl install anyway.
+(contributed by brian d foy)
+
+In general, you can't do this.  There are some things that may work
+for your situation though.  People usually ask this question
+because they want to distribute their works without giving away 
+the source code, and most solutions trade disk space for convenience.
+You probably won't see much of a speed increase either, since most
+solutions simply bundle a Perl interpreter in the final product 
+(but see L<How can I make my Perl program run faster?>).
+
+The Perl Archive Toolkit (http://par.perl.org/index.cgi) is
+Perl's analog to Java's JAR.  It's freely available and on
+CPAN (http://search.cpan.org/dist/PAR/).
+
+The B::* namespace, often called "the Perl compiler", but is really a
+way for Perl programs to peek at its innards rather than create
+pre-compiled versions of your program.  However. the B::Bytecode
+module can turn your script  into a bytecode format that could be
+loaded later by the ByteLoader module and executed as a regular Perl
+script.
+
+There are also some commercial products that may work for
+you, although you have to buy a license for them.
+
+The Perl Dev Kit
+(http://www.activestate.com/Products/Perl_Dev_Kit/) from
+ActiveState can "Turn your Perl programs into ready-to-run
+executables for HP-UX, Linux, Solaris and Windows."
+
+Perl2Exe (http://www.indigostar.com/perl2exe.htm) is a
+command line program for converting perl scripts to
+executable files.  It targets both Windows and unix
+platforms.
+
 
 =head2 How can I compile Perl into Java?
 
@@ -931,8 +932,7 @@ L<perlguts>.  Don't forget that you can learn a lot from looking at
 how the authors of existing extension modules wrote their code and
 solved their problems.
 
-=head2 I've read perlembed, perlguts, etc., but I can't embed perl in
-my C program; what am I doing wrong?
+=head2 I've read perlembed, perlguts, etc., but I can't embed perl in my C program; what am I doing wrong?
 
 Download the ExtUtils::Embed kit from CPAN and run `make test'.  If
 the tests pass, read the pods again and again and again.  If they
@@ -964,8 +964,8 @@ information, see L<ExtUtils::MakeMaker>.
 
 =head1 AUTHOR AND COPYRIGHT
 
-Copyright (c) 1997-2002 Tom Christiansen and Nathan Torkington.
-All rights reserved.
+Copyright (c) 1997-2005 Tom Christiansen, Nathan Torkington, and
+other authors as noted. All rights reserved.
 
 This documentation is free; you can redistribute it and/or modify it
 under the same terms as Perl itself.