From @LLFourn

use MONKEY-SEE-NO-EVAL;

sub MAIN($file) {
  {
  EVAL '=pod ' ~ "a" x 1_000_000;
  }
  note "sleeping -- check memory usage now! for me it gets to ~ 1GB;
  sleep 60;
}

Fairly self explanatory. This leads from perl6/docs htmlify.p6 to take >
1GB over the course of compiling perl6/docs.

2¢​:
Where does this 1GB come from? 1 million 'a's depending on how it's stored
is ~1mb. It is not the data in $=pod that is taking the space. I think it's
the pod string concatenating code in Grammar.nqp, Actions.nqp and Pod.nqp
and associated variables. But they should be freed after the EVALs compile
time. But it looks like they are not.

From @timo

a look at a profile makes me suspect the problem is having pod_string_character match a single character at a time, causing rather large numbers of match objects for comparatively short strings.

It's probably worthwhile to steal a piece of implementation from "nibbling", aka parsing strings. a very short glance points do_nibbling out as interesting.

The RT System itself - Status changed from 'new' to 'open'

From @LLFourn

Probably one of a number of things that would be easy if we made pod
another language on the braid :)

On Mon, Nov 27, 2017 at 11​:59 AM Timo Paulssen via RT <
perl6-bugs-followup@​perl.org> wrote​:

a look at a profile makes me suspect the problem is having
pod_string_character match a single character at a time, causing rather
large numbers of match objects for comparatively short strings.

It's probably worthwhile to steal a piece of implementation from
"nibbling", aka parsing strings. a very short glance points do_nibbling out
as interesting.