Re: Pre-compiled Perl?
by hippo (Bishop) on Apr 03, 2017 at 16:34 UTC
|
Are there ways of getting my code to execute faster?
There are two obvious FAQ entries relating to this: How can I compile my Perl program into byte code or C? and How can I make my Perl program run faster? which may enlighten you.
Perhaps the other obvious action you can take is to avoid Moose. Moose is a great, big, lumbering animal and adds a lot of overhead to any non-persistent system. Consider the lighter weight alternatives, or roll your own or else run the Moosish code as a daemon and have your script just interface with that.
| [reply] [Watch: Dir/Any] |
Re: Pre-compiled Perl?
by afoken (Chancellor) on Apr 03, 2017 at 17:35 UTC
|
Getting rid of Moose sounds like a good idea. There are lighter variations (Moo, Mouse) that may work, but perl can do OO just fine without extra modules.
Also consider using Devel::NYTProf for a much more detailed analysis of your code. Devel::DProf is deprecated, and Devel::NYTProf is the suggested replacement.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [Watch: Dir/Any] |
Re: Pre-compiled Perl?
by shmem (Chancellor) on Apr 03, 2017 at 16:48 UTC
|
Are there ways of getting my code to execute faster?
Yes of course. I don't know how complex your script is, and what tasks it is meant to perform. But from the profiling you can clearly see that the most time is spent with setting up Moose, which is quite heavy and best suited for longer running, complex applications. Check whether you can do without.
Once upon a time, there was a bytecode compiler for perl, but that project has been discontinued. So sorry - no precompiled perl (afaik any "precompiled perl" nowadays isn't, that's just the perl binary, the necessary modules and the script lumped together, with or without obfuscation.)
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] [Watch: Dir/Any] |
|
> Once upon a time, there was a bytecode compiler for perl, but that project has been discontinued.
IIRC it didn't worth it anymore because systems became so fast that compiling didn't count much ... Or at least less than fetching from disc.
For completeness:
We had a discussion if precompiling Moose would help (it wouldn't AFAIR) ... Will add a link later.
updated links
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
|
Re: Pre-compiled Perl?
by Laurent_R (Canon) on Apr 03, 2017 at 16:44 UTC
|
I was under the impression (probably miss guided) that Perl compiled scripts and stored the compiled code somewhere/somehow. If the modification time of the script hadn't changed it would subsequently not need to recompile every time the script was run.
No, that's wrong. The short answer is that a Perl script is recompiled each time it runs.
| [reply] [Watch: Dir/Any] |
|
Sort of picking nits here, but AFAIK Perl5 is never really "compiled." It's executed directly from the parse tree. The parse tree is bulky and full of pointers, making it difficult to store and reload later. (Back in the day, there was a dump/undump mechanism that tried to do this, but it hasn't worked for a long time.)
| [reply] [Watch: Dir/Any] |
|
Yeah, I understand what you mean, but, to me, creating the parse tree is a form of compilation. The difference between compiled languages and interpreted languages was meaningful 20 or 25 years ago, but that distinction is very much blurred nowadays.
Contrary to some other languages (e.g. shell, TCL, awk, makefile), Perl has clearly a compile phase and a run time phase. Whether the compile phase produces an op tree or an executable file has become to a large extent irrelevant in my view. But, yes, it's not really a compilation in the sense of what you do with a C program, you don't produce a binary executable program.
| [reply] [Watch: Dir/Any] |
|
|
|
|
|
|
|
Re: Pre-compiled Perl?
by danaj (Friar) on Apr 04, 2017 at 16:19 UTC
|
Perl quickly demi-compiles everything to an intermediate representation every time you run a program. It doesn't save this intermediate. "Quickly" is of course relative, but it's typically a non-issue on modern computers with reasonable size programs. It was different in the days of 486's (oh the joys of dynamic loading modules in Perl 4 to save startup cost), and it can be an issue with many-thousand line programs. Also a non-issue for most people if your program runs a long time, as do many web frameworks. There is also actual work done for startup on some modules, which is typically very fast but it can add up.
One place it comes up a lot is with small command-line scripts written using Moose. Moose is awesome, but very heavy. Fortunately there is Moo which is a near drop-in replacement for Moose that is much lighter weight. Install Class::XSAccessor as well for a substantial performance improvement for method get/set calls. Moo is, of course, not a complete replacement for Moose, but it does an awful lot. Try it.
You could also try Mouse. These days it isn't as recommended because Moo solves the problem for most people, and Mouse has its own quirks. But it is a lot faster than Moose, so you could give it a try to see if it's worth investigating. It may be as simple as replacing "Moose" with "Mouse" in your files.
There are mechanisms for compiled Perl, or saving the state after the compile phase to avoid the startup, but they mostly just save you the startup time, and have a dodgy history of working. I would recommend against going this direction unless you understand the problem well enough to know this is something you really want. Rieni Urban does some work for CPanel on a compiled Perl but I'm really not up on its status. Restricted Perls such as RPerl are unlikely to help given your problems seem to be with Moose.
I really recommend as well using Devel::NYTProf. It should give a better understanding of what is taking your time. Regardless of changing the OO framework (Moose/Mouse/Moo/Mo/bless), it may be that you're doing something obviously slow once you see the graphs (e.g. maybe you're calling a method get for the same value in a tight loop and could just cache it, or your type constraints are killing you and maybe there's a faster way).
| [reply] [Watch: Dir/Any] |