this article was been updated since its original posting

Rakudo Star was supposed to be a useful and usable subset of Perl 6. It was promised as something "you can use right now". Years after its release, it still does not implement the complete Perl 6.0 specification. It's still by no means the final release. It's still buggy, memory hungry, and slow. While its developers will tell you it's improving, years of work still haven't brought it anywhere close to parity with Perl 5, let alone the vision of what Perl 6 might eventually be.

At the original writing of this article, I believed that "subsequent releases will bring improvements on completeness, correctness, and competitiveness." While that's technically true—it is more complete, more correct with regard to the changing specifications, and has slightly better performance—its progress has been disappointing. I was wrong about its schedule.

This article remains online only for historical interest. It's out of date and misleading. Rakudo's all-but-abandonment of the Parrot virtual machine (and the subsequent diaspora of Parrot developers) have made Parrot a poor choice for the long term plans of Rakudo. (Someone inclined to conspiracies might suggest that this was a goal of the Rakudo developers.) The current state of Rakudo and startup time and benchmarks must thus use the JVM backend, as no other implementation is sufficiently advanced to participate in this benchmark.

I have no connection with Perl 6 and no desire to produce this benchmark. I suspect it would fare badly for Rakudo, but that is supposition not based on evidence.

In late 2010, David Skoll posted a comparison of Rakudo Star to Perl 5.

Rakudo's perl6 binary for the Parrot backend is a couple of hundreds of lines of C code (if that much) linking to libparrot and mostly unoptimized Parrot bytecode. By unoptimized, I mean "There is no optimization of Parrot bytecode in Rakudo Star." — not constant folding, not size optimization, not inlining. None.

The perl5 binary is of course all compiled C code generated (hopefully) by an optimized compiler. Does that make for a valid comparison? I think not.

You cannot easily compare the feature set of the Perl 5 binary to that of Rakudo Star. Perl 5 contains no advanced object system, no grammars, no continuations or coroutines, no junctions, and no interoperability with other languages. It also lacks contain hyperoperators, function and method signatures, multidispatch, laziness, built-in language redefinition, strictness by default, autothreading, REPL, and automatic binding to shared libraries. Somehow Perl 5 programmers manage, mostly by the CPAN:

It's easier to add the loading of the appropriate CPAN modules to the Perl 5 process than to remove them from Rakudo Star, so for an accurate comparison, you must add:

Feature Module Virtual/Resident Memory in KB (cumulative) Startup Cost (cumulative) Parser manipulation Devel::Declare (obsoleted by recent Perl 5 releases) 7356 / 2508 0.024s Advanced object system Moose and MooseX::Declare 18184 / 13064 0.705s autoboxing autobox, autobox::Core, and Moose::Autobox 19884 / 14732 0.777s Coroutines Coro 20276 / 15020 0.783s Parse tree manipulation B::Generate 20328 / 15080 0.799s REPL Devel::REPL 21132 / 15860 0.827s Multidispatch MooseX::MultiMethods 22076 / 16832 0.987s Function signatures signatures 22144 / 16920 0.992s Shared library bindings FFI 22188 / 16976 0.995s Perl 5.12 features feature 22216 / 16976 0.997s Grammars Regexp::Grammars 22780 / 17576 1.017s Parrot language interoperability Parrot::Embed (obsolete with the deprecation of Parot) 40812 / 18476 1.020s

I ordered the list in terms of dependencies to show cumulative costs. I also left out a few CPAN distributions you need to add to Perl 5 to add features enabled by default in Perl 6: for example, I couldn't get Data::Alias to build.

My perl5 binary is Perl 5.12.1, built fresh today as a 32-bit binary without threading. (A 64-bit binary uses more memory and a binary with threading is some 10-15% slower, reportedly.) It's 1,239,686 bytes in size.

My perl6 binary (built from today's checkout, not Rakudo Star) is 14,280,276 bytes in size. At the REPL, it uses 99,944 KB of virtual memory and 81,132 KB of resident memory. To run the program -e 1 , it requires 1.035s. By my calculations, Rakudo Star starts up 1.5% more slowly than Perl 5 with all of the other modules loaded and uses 2.45 times as much virtual memory and 4.39 as much resident memory.

By way of comparison, Perl 5 running -Mperl5i::2 -E 1 runs in 0.149s. It requires 12,080 KB of virtual memory and 6,952 KB of resident memory. Rakudo Star starts 6.72 times slower than Perl 5 with perl5i. Rakudo Star uses 8.27 times more virtual memory and 11.67 times more resident memory.

Remember; those were numbers in mid-2010. Compare Perl 5.18.2 (which has had feature enhancements and optimizations) to a recent Rakudo Star release on the JVM and you will see different numbers.

Of course, if you're comparing the ability of either language to let you get things done... well, Perl 5 still comes out ahead.