A short example of Parrot GC pain

[chromatic]

On Sunday 05 September 2010 at 13:32, Patrick R wrote:

> 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.

How does the example fare for you with this patch?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_gc_in_mem_allocate.patch
Type: text/x-patch
Size: 2186 bytes
Desc: not available
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20100905/fd851524/attachment.bin>