From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 61742BB84 for ; Tue, 15 Jul 2008 11:12:26 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIMGfEhQRFuw/2dsb2JhbACuGA X-IronPort-AV: E=Sophos;i="4.30,365,1212357600"; d="scan'208";a="15117153" Received: from furbychan.cocan.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 15 Jul 2008 11:12:26 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1KIga2-0005aC-VZ; Tue, 15 Jul 2008 10:12:19 +0100 Date: Tue, 15 Jul 2008 10:12:18 +0100 To: Arthur Chan Cc: Jake Donham , caml-list@yquem.inria.fr, Raj Bandyopadhyay Subject: Re: [Caml-list] Q: Profiling ocaml using gprof Message-ID: <20080715091218.GA20823@annexia.org> References: <74cabd9e0807142242n3854dcf7w6d0cfacb0ca6d6a3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74cabd9e0807142242n3854dcf7w6d0cfacb0ca6d6a3@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; ocaml:01 ocaml:01 ocaml's:01 bytecode:01 annotations:01 stub:01 mangling:01 printf:01 printf:01 compiler:01 ml':01 compiler:01 ocamlopt:01 binutils:01 binutils:01 On Mon, Jul 14, 2008 at 10:42:39PM -0700, Arthur Chan wrote: > Is gprof better for profiling ocaml than ocaml's own profilers? They are slightly different. I use 'gprof' all the time because I tend to only use natively compiled executables. 'gprof' is the ordinary GNU profiling tool that tells you which function is being run most often and some limited information about the call path into that function. It's pretty useful for simple profiling where you're looking for obvious problems. 'ocamlprof' is a bit different. Last time I used it [which was a few years ago, so maybe it's different now], it only worked on bytecode. It outputs your original code with annotations telling you how often each expression was run. So this isn't time taken (each expression can take a different amount of time to execute, and this time isn't shown), but how often a particular path through the code is taken. > How would you go about figuring out that that particular function stub is > string concat? > 'camlPervasives__$5e_136'. In 'gprof' there's a simple name mangling used to map OCaml function names to assembler symbols. Once you understand it, you'll find it easy to follow. First of all note that OCaml function names aren't unique, eg in the following code: let f () = printf "this is the first f()\n" let f () = printf "this is the second f()\n"; f () ;; f () The assembler symbol is: "caml" ^ Modulename ^ "__" ^ functionname ^ "_" ^ uniquenumber 'uniquenumber' is just a counter added to function names by the compiler to make sure that functions which have the same name will have different symbols. So when I compiled the code above in a file called 'test.ml' (hence a module called Test), in my case I ended up with two symbols called: camlTest__f_77 camlTest__f_78 where '77' and '78' are arbitrary. You can check this by looking at the assembler output from the compiler (ocamlopt -S). If a function name contains an operator symbol (eg. (^) ) then a $xx hex code is used. I guess in theory one could write an OCaml symbol filter, similar to c++filt [http://sourceware.org/binutils/docs/binutils/c_002b_002bfilt.html] Rich. -- Richard Jones Red Hat