On Apr 29, 2009, at 9:03 AM, Markus Mottl wrote:
> On Wed, Apr 29, 2009 at 10:48, Damien Doligez  
> <damien.doligez@inria.fr> wrote:
>> Markus, you put your finger right on the problem.  That program  
>> doesn't
>> suddenly start to get slow, it gets steadily slower as it runs.  The
>> heap also gets steadily bigger, and the major GC does way too much
>> work.
>
> Right, the combination of forcing the GC very often through PCRE and
> keeping an ever increasing number of values around obviously leads to
> this slowdown.

Makes sense.  (Though, i'd point out that there *are* discrete moments  
of sudden slowdown -- after each parse completes.  Maybe the GC  
doesn't scan through the results until they are returned by the parse  
function...?)

>> Maybe PCRE should change its settings to trigger GCs less often but,
>> as Markus said, this doesn't look really important.
>
> I've never seen a case in practice where correctly done regexp
> allocations happen so often that excessive full major collections are
> triggered.  There is no optimal "general" setting for how aggressive
> the GC should be with regexps, but the current value should work fine
> for just about anybody.  A still reasonable higher setting would
> probably not solve performance bugs of the sort above anyway.

You seem to have solved my problem.  But out of curiosity:  Do you  
know how the GC settings in the Str library differ from PCRE's, and  
why?  Why does PCRE need to explicitly trigger GCs at all?

Thanks for your replies,
~Brighten