From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA32669; Mon, 2 Jul 2001 15:16:52 +0200 (MET DST)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA32665 for <caml-list@pauillac.inria.fr>; Mon, 2 Jul 2001 15:16:51 +0200 (MET DST)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f62DGob13191;
	Mon, 2 Jul 2001 15:16:50 +0200 (MET DST)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA32661; Mon, 2 Jul 2001 15:16:49 +0200 (MET DST)
Date: Mon, 2 Jul 2001 15:16:49 +0200
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Florian Hars <florian@hars.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Where does Ocaml spend all the time?
Message-ID: <20010702151649.A32562@pauillac.inria.fr>
References: <20010628101635.A25747@hars> <20010628103724.A11414@pauillac.inria.fr> <20010628120229.B25747@hars>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20010628120229.B25747@hars>; from florian@hars.de on Thu, Jun 28, 2001 at 12:02:29PM +0200
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

> Yes, that is one of the functions that I expected to take a lot of time,
> since the program does a lot of string comparision and matching.
> I was more surprised by the time spent in the <Modulename>_code_(begin|end)
> functions, what are these? Why are they called and by whom?

It's an artefact of gprof.  For each module, ocamlopt generates two
code symbols <Modulename>_code_begin and <Modulename>_code_end
that bracket the code for this module.  (These symbols are used to
determine the address range for the compiled code during marshaling.)
So, if you have two modules A and B and the first function in B is f,
you'd get something like:

        A_code_begin:
          ...
        A_code_end:
        B_code_begin:
        B_f:
          ... code for B.f ..
        ...
        B_code_end

and gprof now has three names to refer to the entry point of B.f:
B_f, A_code_end and B_code_begin, hence a 2 in 3 chance that it will
pick the wrong name :-)  

This could be fixed by inserting "nops" around the _code_begin and
_code_end symbols, at least when compiling in profiling mode.

> > At any rate, the GC-related functions account for only 25% of the
> > running time (which is typical for symbolic processing, but a bit high
> > for numerical processing)
> 
> So this is OK (except that it is 25% of quite a lot of time :-)

It's for programs that allocate a lot.  A C or C++ program with the
same allocation behavior would typically spend 50 to 90% of its time
in malloc() and free()  :-)

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr