A short example of Parrot GC pain

[Patrick R. Michaud]

As reported a short while ago on #perl6 and #parrot:

  pmichaud at orange:~/rakudo$ cat x.pir
  .loadlib 'io_ops'
  
  .sub 'main'
      $P0 = open 'unixdict.txt', 'r'
      $P0.'encoding'('utf8')
      $S0 = $P0.'readall'()
      $P0.'close'()
      $I0 = length $S0
      say $I0
  .end
  
  pmichaud at orange:~/rakudo$ time parrot_install/bin/parrot x.pir
  206403
  
  real	0m2.327s
  user	0m2.310s
  sys	0m0.020s

  pmichaud at orange:~/rakudo$ diff x.pir y.pir
  3a4
  >     load_bytecode 'perl6.pbc'

  pmichaud at orange:~/rakudo$ time parrot_install/bin/parrot y.pir
  206403
  
  real	0m22.983s
  user	0m22.380s
  sys	0m0.160s

:-(

Notes:
1.  It only takes about a second for y.pir to complete the 
    C<load_bytecode 'perl6.pbc'> step -- the increase in 
    execution time is almost entirely in the .'readall' method.
2.  There's no "large Rakudo parse tree or ast" lying around 
    that would be artificially increasing the work of the GC -- 
    this is truly compiled code.
3.  The code in y.pir is running entirely in the 'parrot' HLL
    namespace, there are no Rakudo-specific PMCs, subroutines,
    dispatchers, etc. being used once the load_bytecode has
    completed.

Pm