English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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

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