Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Performance penalties of in-Perl docn vs compiled CGIs.

by GrandFather (Saint)
on Feb 02, 2021 at 05:37 UTC ( #11127796=note: print w/replies, xml ) Need Help??


in reply to Performance penalties of in-Perl docn vs compiled CGIs.

"... what performance penalty I'm paying for including documentation in my Perl CGI scripts ..."

Effectively none. Perl compiles your code to an internal form at run time at which point any comments and pod become irrelevant. There is no "Perl compiler". For websites with modest traffic you can pretty much ignore any startup overhead that is incurred by perl getting going. If you have a high traffic site it may be worth investigating mod_perl and its ilk.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
  • Comment on Re: Performance penalties of in-Perl docn vs compiled CGIs.

Replies are listed 'Best First'.
Re^2: Performance penalties of in-Perl docn vs compiled CGIs.
by ikegami (Pope) on Feb 05, 2021 at 00:03 UTC

    Effectively none. Perl compiles your code to an internal form at run time at which point any comments and pod become irrelevant

    It doesn't really add to the compile time either. Skipping over POD is computationally trivial.

    Seeking work! You can reach me at ikegami@adaelis.com

Re^2: Performance penalties of in-Perl docn vs compiled CGIs.
by phirun (Novice) on Feb 02, 2021 at 05:55 UTC
    Thanks for your reply. I'm aware of the differences between complied and interpreted languages, and that the latter CAN be compiled into an executable. Searching the Net for "Perl compiler" returns a swag of results, and I've long been aware of one or more "Perl compiler projects". Relevant info is available here: https://www.marcbilodeau.com/compiling-perl/ I'm also aware that Perl uses a two-pass interpreter, that the first pass tokenizes the commands whilst dropping extraneous matter. I'm also aware that the milliseconds required to do this by gigahertz CPUs is all but instantaneous. My question is therefore more about ... ? aesthetics and elegance than mere time-of-execution. However, such seemingly intellectual approaches can have practical consequences further down the development track.

      I was befuddled by your talk of "C executables" into thinking you were new to the concept of compilers, interpreters and executable code, maybe you are. "Executables" are generally considered independently of the language that was used to create them so it is unusual to talk of C Executables.

      If is not universally the case that interpreted languages can be compiled. In the general case it is not true that Perl can be compiled in the usual sense to generate an executable. There are packaging tools that pack a Perl script up with everything it depends on and a Perl interpreter into and executable that is unpacked at run time, but that is not compiling. There are compilers that can compile scripts written in a subset of Perl, but those aren't Perl compilers either.

      You are right to think that raw time of execution is almost never interesting these days and that will become more true as time goes on. The more important metric is ease of maintenance and that points directly at documentation, automated testing and perhaps code coverage metrics.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

      Perl5 compiles the source code into OPCODE objects, then interprets (loops over) the OPCODE objects.

      Seeking work! You can reach me at ikegami@adaelis.com

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11127796]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2021-04-10 22:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?