5

I have been working on a Perl parser on and off for a few years, though since it has always been in pre-alpha, I have never worried about speeding it up. However, I have started working on ways to optimize it, and was surprised at what I found.

After some algorithmic and regex optimizations, a normal execution takes around 3.5 seconds, of which, about 2.3 is the time it takes for Perl to start up (which I measured with "time perl scriptname.pl" after putting a "die("Done");" in the first line). I understand that Regexp::Grammars isn't the speediest Perl module out there, but it seems that its initialization takes much longer than actually executing the script.

Therefore, I started looking into an easy way of compiling it down to bytecode before running it. It seems B::Bytecode, the only functional way to do this, is no longer maintained or included in the main Perl distribution. Is there any easy way for me to decrease the startup time?

Thanks!

user2150378
  • 51
  • 1
  • 1
    What modules does your parser use besides Regexp::Grammars? – DavidO Dec 14 '13 at 20:08
  • Compiling Regexp::Grammars takes only 0.03s on my system. It's probably the initialization of internal Regexp::Grammars structures which is slow here, but compiling to bytecode would not help in this case (but maybe some kind of serialization of the internal state?). – Slaven Rezic Dec 14 '13 at 20:08
  • 1
    I'm under the impression that B::Bytecode actually made things *slower* – ikegami Dec 15 '13 at 07:25
  • 2
    Profile the execution with [`Devel::NYTProf`](https://metacpan.org/pod/Devel::NYTProf), *then* optimize the slowest part. Don't waste your time by *guessing* (humans are really bad at estimating performance). – amon Dec 15 '13 at 09:04
  • 1
    Thanks amon. I managed to trace it down to a call within Text::Balanced, which seems to be called by Regexp::Grammars internally. – user2150378 Dec 20 '13 at 15:36

1 Answers1

0

There are ways to run persistent scripts. Usually they're used in a webserver context, but there's no reason not to use them for other purposes.

One such system is CGI::SpeedyCGI, which may or may not be what I was thinking of. This is currently also known as PersistentPerl.

matt freake
  • 4,877
  • 4
  • 27
  • 56
bart
  • 7,640
  • 3
  • 33
  • 40