in reply to Re: Rakudo Perl 6 and MoarVM Performance Advances
in thread Rakudo Perl 6 and MoarVM Performance Advances

.lines() and -n are really really slow in rakudo, the code behind that is not really clever, compared to the code in Perl 5 (there is a talk by leont about what P5 does there).

This should be better:

perl6 -e 'grammar G { token TOP { <line>* }; token line { \N*\n } }; class A { method line($m) { say ~$0 if $m ~~ m/(<<\w**5>>)/ } }; G.parse(slurp(), :actions(A))'

If tested that on a file from my box, result:

Perl 5: 0.2s

Perl 6: 6.2s

That would mean that it might take about 45s on your box... can you verify that?

Note 1) String handling is the slowest part in rakudo atm.

Note 2) You should not compare printing the .gist of a match to a string from another language. Because Date::Dumper-ing an object in P5 is not really fast either. And that is what .gist somewhat is. (.gist is the human friendly nice formatted version of Data::Dumper aka method .perl)

Note 3) I promised to look into the cheats P5 does when walking over lines, and I'll do that this weekend.

Replies are listed 'Best First'.
Re^3: Rakudo Perl 6 and MoarVM Performance Advances
by gunzip (Pilgrim) on Sep 05, 2014 at 17:04 UTC

    Results for a similar 19MB log file on my 2013 Macbook Pro:

    Perl 5: 0.68 secs
    Perl 6/Grammar: 49.8 secs

    so 73 times slower.

      Aiui your 73X slower result came purely from changing your code, not an improved compiler. Right?

      A variety of related changes to the compiler (and its toolchain) have since landed in the Rakudo, NQP and MoarVM HEADs. Aiui these will deliver significantly better results for both your original and grammar versions.

      The really big upcoming performance breakthrough for P6 will be the "Great List Refactor". The GLR, which has been discussed for years, is expected to have a very big impact on the execution speed of lists, arrays, etc. in typical code, substantially reducing RAM usage too in many scenarios.

      PerlJam recently said he's "working on a TPF grant to pay for having jnthn, TimToady, and pmichaud kidnapped and locked in a room" to do the GLR. Joke or not, it reflects the practical bus number on this (three, imo) and the ideal scenario (all three focusing on the GLR for a few weeks).

      Larry Wall, who has been getting his hands increasingly dirty for a year or so now (hacking on Rakudo and its toolchain), has been preparing for the GLR by reading guts code, profiling, and landing various related changes over the last few months. Larry's recent discussion of some things the GLR will take in to account may be of interest.

      Fwiw, when PerlJam recently wondered aloud "if it's worth adding GLR to S99", Larry responded "I hope to make the term obsolete pretty soon". Here's hoping we'll see a big GLR performance jump this year.

      One can reasonably expect significant further performance improvements every month for years to come. This year has seen Rakudo, NQP and MoarVM gain classic optimization phases, frameworks and tools. Some work taking advantage of these has already happened, so there have already been big improvements many months this year, but a lot of improvement is still ahead of us. For example the MoarVM JIT is in good shape in the sense it works and already slightly speeds up some code, but most of the benefits are yet to come.