From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q32DenH8007892 for ; Mon, 2 Apr 2012 15:40:49 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUCACKreU/RVdK2gGdsb2JhbABFuQgIIgEBCwcCDQcUJ4IJAQEBAwESAiwBGx0BAwwGBQQBBg0uIgERAQUBHAYTIodiBZxzCowWgnGEYT+IdgEFC5ERBJVhjlA9hAs X-IronPort-AV: E=Sophos;i="4.75,357,1330902000"; d="scan'208";a="152317093" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Apr 2012 15:40:43 +0200 Received: by iahk25 with SMTP id k25so6977257iah.27 for ; Mon, 02 Apr 2012 06:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zkpfz3ibcms82r5Bo88RgjbZDTWZyRkUUZ8S4zCJabQ=; b=afwvIZ29ZUXHwlSDBcTZbJUWZoCK2C1eLlR5ym1EdrWeWmtEP9oGyLVM79gsJpE11t C9rrlSD3L0KKIdp70tpeql3PE7NwCxNVt6mCyMKONp9PhEN9qGNJ44stKXCydBdbZsiX R0p3i47qB2qRN9F9gqKuGW0I6QcCCelnxdKQIwiGKqwuJMfTooe6rYvFYwEMiy+ET2MR 3AuR5PUZ2boGQ57bMsM5qUjCXirfSFS8jqDsiCPqf+2XoR4GAtYXxXHTHhv3r0RPQ3t1 erYYKl4xI+82gCxCQL+7RDdNVPaOwFxKET3fENVfEWgIVzcSctzz6aQeRGbp417zjZ5D l2jg== MIME-Version: 1.0 Received: by 10.42.176.6 with SMTP id bc6mr4470406icb.49.1333374042344; Mon, 02 Apr 2012 06:40:42 -0700 (PDT) Received: by 10.42.117.67 with HTTP; Mon, 2 Apr 2012 06:40:42 -0700 (PDT) In-Reply-To: <20120402101352.GA1370@annexia.org> References: <20120401195733.GB15870@annexia.org> <20120402101352.GA1370@annexia.org> Date: Mon, 2 Apr 2012 15:40:42 +0200 Message-ID: From: Hans Ole Rafaelsen To: "Richard W.M. Jones" Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=90e6ba6e9014258cc204bcb256fd Subject: Re: [Caml-list] Strategies for finding memory leaks --90e6ba6e9014258cc204bcb256fd Content-Type: text/plain; charset=ISO-8859-1 Just did another run to be sure. It does not do any swapping. -- Hans Ole On Mon, Apr 2, 2012 at 12:13 PM, Richard W.M. Jones wrote: > > On Mon, Apr 02, 2012 at 10:15:02AM +0200, Hans Ole Rafaelsen wrote: > > However, the application still consumes more and more CPU time. And it > > seems to happen in the GC. Apart from that, the application seems to be > > just fine. So it seems to be something in our code (or in LablGTK) that > is > > making the GC spend more and more time. Anyone experienced this kind of > > problem? > > You're not swapping are you? (Run 'vmstat 1' & look at the si/so columns) > > Rich. > > -- > Richard Jones > Red Hat > --90e6ba6e9014258cc204bcb256fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just did another run to be sure. It does not do any swapping.

-- Hans Ole

On Mon, Apr 2, 2012 at 12:13 PM= , Richard W.M. Jones <rich@annexia.org> wrote:

On Mon, Apr 02, 2012 at 10:15:02AM +0200, Hans Ole Rafaelsen wrote:
> However, the application still consumes more and more CPU time. And it=
> seems to happen in the GC. Apart from that, the application seems to b= e
> just fine. So it seems to be something in our code (or in LablGTK) tha= t is
> making the GC spend more and more time. Anyone experienced this kind o= f
> problem?

You're not swapping are you? =A0(Run 'vmstat 1' & loo= k at the si/so columns)

Rich.

--
Richard Jones
Red Hat

--90e6ba6e9014258cc204bcb256fd--