Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Strange performance bug
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-04-29 (19:19)
From: Brighten Godfrey <pbg@c...>
Subject: Re: [Caml-list] Strange performance bug
On Apr 29, 2009, at 9:03 AM, Markus Mottl wrote:
> On Wed, Apr 29, 2009 at 10:48, Damien Doligez  
> <> 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  

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