From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E504A7F98F for ; Wed, 9 Aug 2017 09:37:51 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=kennethadammiller@gmail.com; spf=Pass smtp.mailfrom=kennethadammiller@gmail.com; spf=None smtp.helo=postmaster@mail-lf0-f53.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.215.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.215.53 as permitted sender) identity=mailfrom; client-ip=209.85.215.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f53.google.com) identity=helo; client-ip=209.85.215.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-lf0-f53.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3Aixz73xEDnLdSeLpQ59VZL51GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ78osWwAkXT6L1XgUPTWs2DsrQf2rqQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbQhFgDmwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VDK/5KlpVRDokj?= =?us-ascii?q?8KOT43/m/Ul8J+kr5UrQm7qBBj2YPZep2ZOOZ8c67bYNgURXBBXsFUVyFZB42z?= =?us-ascii?q?cY0PD+wfMuZEr4n2ukcDogakCgmpGejhzT5Ihnvy3aIkyeQqDAbL3A8+ENIItn?= =?us-ascii?q?Tbssn1NKcIXu+o1qbIyDDDb/JS2Tf59ofIaAssof6JXb1qcMrRzVMjGB/CjlWV?= =?us-ascii?q?sIHoOS6e2OcVs2WD8eZsSeaih3QkpgxxuDSj2Nogh4nTio8VxF3J8zhyzpwvKt?= =?us-ascii?q?2iUkF7ZMapEJtOuCGeMIt7WsYiTHtpuCY+07EGvZC7cDQTxJQpxxPSZeaLc4eP?= =?us-ascii?q?4hLkW+aRJSl3iGh5d7K4gha+6UmgyuviWcmoyFtGsDZJn93Wun0O1xHf8NaLRu?= =?us-ascii?q?Z980u72TuC2Rjf6uReLkA1karbJYQhwrk1lpcLskTMACn2mEPog6+KdkUr4PWn?= =?us-ascii?q?5P7iYrXjp5+cM4t0hR/kMqk1lcy/BP43MgkKX2SB5eu807jj8VXjQLpWlv02jr?= =?us-ascii?q?XZsJfCKMsHvKG5BgtV3p8n6xa+FDemzM8VnWIHLVJAYBKIlZLlO1DIIPDiDPew?= =?us-ascii?q?mU6gkDlxx6OOArq0CZzIKjDei7r7Zv4p4EdZzE83zMtDz5NSELAIZvzpDBzfrt?= =?us-ascii?q?vdWzw0NQq53+avIdl008s7WGaLD7XRZKDft1mF+uImL+CJYY4RvDvnA/cg7v/q?= =?us-ascii?q?y3Q+nAlOLuGSwZILZSXgTbxdKEKDbC+0jw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCCAD6uopZhjXXVdFcHQEXAQYBCwEXA?= =?us-ascii?q?QYBgnVSAYFSB4UlmGmLFIc8h0UOiigHQxQBAQEBAQEBAQEBARIBAQEICwsIKC+?= =?us-ascii?q?CMyKCbR0BGx4DEgkHNwIkAREBBQEiiikBAxWeDYNFP4wKggQFARyDCQWDWQoZJ?= =?us-ascii?q?w1Wg2cCBhKDFoICjlyCYQWgFoFokk6ST5RDFB+BFTaBKzIhJHiEfRAMggMkNoo?= =?us-ascii?q?SAQEB?= X-IPAS-Result: =?us-ascii?q?A0BCCAD6uopZhjXXVdFcHQEXAQYBCwEXAQYBgnVSAYFSB4U?= =?us-ascii?q?lmGmLFIc8h0UOiigHQxQBAQEBAQEBAQEBARIBAQEICwsIKC+CMyKCbR0BGx4DE?= =?us-ascii?q?gkHNwIkAREBBQEiiikBAxWeDYNFP4wKggQFARyDCQWDWQoZJw1Wg2cCBhKDFoI?= =?us-ascii?q?CjlyCYQWgFoFokk6ST5RDFB+BFTaBKzIhJHiEfRAMggMkNooSAQEB?= X-IronPort-AV: E=Sophos;i="5.41,346,1498514400"; d="scan'208,217";a="286536654" Received: from mail-lf0-f53.google.com ([209.85.215.53]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 Aug 2017 09:37:51 +0200 Received: by mail-lf0-f53.google.com with SMTP id g25so24401900lfh.1 for ; Wed, 09 Aug 2017 00:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xmyBYp/Cmw3NrKbzgU8os2oPhN4XQixc+5iai6TWHQg=; b=oMiqshku+TnVnUPvkExhbNknZKidIGCKzKziMeI2hmRr6DI7lMSdpgjqqrt2TxtdnD xGlKxGQ/EPyDol02rMJyaG33LSk2b8Fb87VEQK4TF8IFu8O/kVd3FiW5qAblJdEyEYLQ qbX2FhPAg4ZMaeY6gqVq/16MCn3gjfc+SHmuJOCtMPXPAzOcvLOU4c6kff0/qKJkFE/u x4+XAxoJdbjRLEtqzwtdiO5lr9TRIvQ73dzu41fe5rZB77s5HpNwoXqqdi1I8Rx9RrlO zKvMOwPaRxdmmh64Cp/rj/7a3WuTKNtLTcoOufzAOc+sN95csPJKyIJ1Ftnj3zRs+rs6 mtwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xmyBYp/Cmw3NrKbzgU8os2oPhN4XQixc+5iai6TWHQg=; b=qktE4Z2Iz955hMkxs8UGj80dZyalSCage1qhS1WSYS+ie+/bZ5TUv0bHFSmfxf2wQ6 iC8wKMSZ2tImr9C5YPw0HDvN1qvlSEdgkMGbAxQG3zBeZeuqYg/ANGrk0k71GJSQR0Og sCQbbQ3eBwumrpOaCYfuwjmsGlEIi6TRHa9ROXMm6tCctYMd2lzwtNOoaJEhHsiiz5dF VjxyicmynTDeIQvw7JOee9qxsVBR1Eeh4NoKhMrilGOjRn4huWaa4U+ajq7HWTiEhQfc 1rnAxomKr2S1gfOzowZfIKN6DKAMt67xfPbX8OEECWChQwZSVI7N21sQOaePnuvD1QtL 67fQ== X-Gm-Message-State: AHYfb5h/AlAA+b2a5uAFCTOjsQ6RD/J6/LmTv/ANPy2vg3BmTo2EFqYF 2ZJeaw4mlWGbyoHW5fHuTn8+YJ12zCpkOdo= X-Received: by 10.25.19.24 with SMTP id j24mr2581256lfi.54.1502264270374; Wed, 09 Aug 2017 00:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Wed, 9 Aug 2017 00:37:49 -0700 (PDT) From: Kenneth Adam Miller Date: Wed, 9 Aug 2017 03:37:49 -0400 Message-ID: To: caml users Content-Type: multipart/alternative; boundary="001a114019b431cc9605564d28fb" Subject: [Caml-list] Overflow with Spacetime --001a114019b431cc9605564d28fb Content-Type: text/plain; charset="UTF-8" Hello all, I wrote a particular application, and after profiling I can see that the garbage collector is using 95% of the time in the application and that it uses up to 6 gigs of memory on a 1 megabyte input file for a run that totals out to be about 2 minutes. A 27 kilobyte input file takes seconds to run, so I know that there is some explosive leak or otherwise terrible issue with the space complexity here. I doubled down, and got compilation to run to completion using _tags to make sure that there were symbols and profiling turned on (thanks Ivan, Drup). Additionally, I compiled my application with spacetime and ran it to obtain a `spacetime-` binary, which I then attempted to get a report on with prof_spacetime. prof_spacetime went up to about 7.3 gigs in memory usage before it repeatedly would die with `Killed` or `Stack overflow` as the error. I'm trying to figure out what else there is I can do to make sure that the process runs to completion. I double checked to make sure that I was running the prof_spacetime command built with just a 4.04.0 compiler to ensure that it wouldn't profile itself while trying to "Process series". My spacetime dump is about 900 Mb, so I understand that it would use some memory processing it. Possibly I ran into a space leak while trying to find a space leak. In the meantime, I will try and find some intermediate size input to get something I can work on - thought I should report this. --001a114019b431cc9605564d28fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,


I wrote a par= ticular application, and after profiling I can see that the garbage collect= or is using 95% of the time in the application and that it uses up to 6 gig= s of memory on a 1 megabyte input file for a run that totals out to be abou= t 2 minutes. A 27 kilobyte input file takes seconds to run, so I know that = there is some explosive leak or otherwise terrible issue with the space com= plexity here. I doubled down, and got compilation to run to completion usin= g _tags to make sure that there were symbols and profiling turned on (thank= s Ivan, Drup).=C2=A0

Additionally, I compiled my application with sp= acetime and ran it to obtain a `spacetime-<pid>` binary, which I then= attempted to get a report on with prof_spacetime. prof_spacetime went up t= o about 7.3 gigs in memory usage before it repeatedly would die with `Kille= d` or `Stack overflow` as the error. I'm trying to figure out what else= there is I can do to make sure that the process runs to completion. I doub= le checked to make sure that I was running the prof_spacetime command built= with just a 4.04.0 compiler to ensure that it wouldn't profile itself = while trying to "Process series". My spacetime dump is about 900 = Mb, so I understand that it would use some memory processing it. Possibly I= ran into a space leak while trying to find a space leak.=C2=A0

In t= he meantime, I will try and find some intermediate size input to get someth= ing I can work on - thought I should report this.

=
--001a114019b431cc9605564d28fb--