Background:
I have a program that uses PDF:API2 to generate pdf files based on
html text and images. When done it then generates preview images of
the pages using Imagemagik. The program does not interaface with the
web so there is no communication with a browser.

The questions I have are, is there any significant speed increase
going to mod_perl or even compiling it to an executable? From what I
have heard and read (and this could be wrong), the mod_perl just keeps
it in memory so that it is faster getting started and that compiling
just wraps the code in a perl script interpreter (for lack of a better
term). Are these true?

Looking at perldoc perlcompile it mentions that it will make C source
out of your perl script but then gives caveats about how it is
incomprehensible. Discounting this, since I could always make changes
to the perl code and "re-compile", does it actually make c source will
compile to an executable? What about included Libs (such as the
PDF:API2)? Do they get "compiled" also?

Bill H

Bill H wrote:
> Background:
> I have a program that uses PDF:API2 to generate pdf files based on
> html text and images. When done it then generates preview images of
> the pages using Imagemagik. The program does not interaface with the
> web so there is no communication with a browser.

That modules runs quite quickly, but has a filthy
startup time, mainly spent loading complex
font information that may well not be used.

I once tried to defer this, and implement "load on demand",
but gave up.

   BugBear

Bill H <bill@ts1000.us> wrote in news:24e1c65f-4fc3-4b37-a044-
fcb46fb00020@b1g2000hsg.googlegroups.com:

> Background:
> I have a program that uses PDF:API2 to generate pdf files based on
> html text and images. When done it then generates preview images of
> the pages using Imagemagik. The program does not interaface with the
> web so there is no communication with a browser.
> 
> The questions I have are, is there any significant speed increase
> going to mod_perl

mod_perl works within Apache, so I don't think it is relevant to your 
situation.

> or even compiling it to an executable? From what I
> have heard and read (and this could be wrong), the mod_perl just keeps
> it in memory so that it is faster getting started and that compiling
> just wraps the code in a perl script interpreter (for lack of a better
> term). Are these true?

Yes. In the most naive scenario, mod_perl represents a speedup over CGI 
by not going through the whole invoke perl, compile modules etc routine 
every time a Perl script is invoked via Apache.

Yes to the second question as well.

> Looking at perldoc perlcompile it mentions that it will make C source
> out of your perl script but then gives caveats about how it is
> incomprehensible. Discounting this, since I could always make changes
> to the perl code and "re-compile", does it actually make c source will
> compile to an executable? What about included Libs (such as the
> PDF:API2)? Do they get "compiled" also?

I do not know the internals. I do not care about the internals. 

If you are looking to speed up your program, trying to compile to C is 
the last avenue you should be considering. It is better to look at how 
your program does what it does and identify what it does slowly and 
which of those tasks that it does slowly represents opportunities for a 
speed-up by changes to code or algorithm.

http://www.perl.com/pub/a/2001/06/27/ctoperl.html

http://www.perl.com/pub/a/2004/06/25/profiling.html


Sinan



-- 
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

On Wed, 03 Sep 2008 14:30:20 +0100, bugbear wrote:
> Bill H wrote:
>> Background:
>> I have a program that uses PDF:API2 to generate pdf files based on
>> html text and images. When done it then generates preview images of
>> the pages using Imagemagik. The program does not interaface with the
>> web so there is no communication with a browser.
> 
> That modules runs quite quickly, but has a filthy
> startup time, mainly spent loading complex
> font information that may well not be used.

That suggests that Persistent Perl (http://daemoninc.com/PersistentPerl/)
would be a good idea, but it hasn't been updated in ages.  Anyone know of
a successor?

-- 
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/

Peter Scott <Peter@PSDT.com> writes:
> 
> That suggests that Persistent Perl (http://daemoninc.com/PersistentPerl/)
> would be a good idea, but it hasn't been updated in ages.  Anyone know of
> a successor?
> 

If it ain't broke, why fix it?

On Thu, 04 Sep 2008 09:48:52 -0500, Lawrence Statton wrote:
> Peter Scott <Peter@PSDT.com> writes:
>> 
>> That suggests that Persistent Perl (http://daemoninc.com/PersistentPerl/)
>> would be a good idea, but it hasn't been updated in ages.  Anyone know of
>> a successor?
>> 
> If it ain't broke, why fix it?

It is broken:

http://rt.cpan.org/Public/Bug/Display.html?id=33287

Patch submitted but not applied.

-- 
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/

On 2008-09-03 11:59, Bill H <bill@ts1000.us> wrote:
> From what I have heard and read (and this could be wrong), 
[...]
> compiling just wraps the code in a perl script interpreter (for lack
> of a better term). Are these true?

That depends on the "perl compiler". The programs which turn a perl
program into an executable, usually just pack the perl program, the
modules it uses and a perl interpreter into an executable. They are
sometimes calles "compilers", but the don't compile (in the IT sense of
the word) anything.

> Looking at perldoc perlcompile it mentions that it will make C source
> out of your perl script but then gives caveats about how it is
> incomprehensible.

Perlcc is the exception. Perlcc really translates Perl into C which can
then be compiled into a native executable. The problem is that it
doesn't work for most Perl programs. It is considered a failed
experiment and has been removed from perl 5.10.

	hp