Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Caml performance
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: Caml performance
> I've been trying to compile OCaml to be instrumented with gprof.  When I do
> so, it's possible to get profile information for the ocamlrun executable
> (the interpreter), but not for any of the additional libraries (like Unix
> and Threads), presumably because they are "linked" in with the bytecode file
> that's being executed, but do not reside in the ocamlrun executable itself.

Yes, in some sense.  If you use external libraries, a special-purpose
runtime system is created and linked with your program, and the
ocamlrun executable itself is not used at all.

> Is there any way around this?  In particular, I'm trying to find out how
> much time is spent in the thread scheduler, and gprof seemed like a good way
> to find this out.

A simple way to do this is to recompile the whole OCaml distribution
with the "-p" flag.  In config/Makefile, add "-p" to the variables
BYTECCCOMPOPTS and BYTECCLINKOPTS.  Then do make clean; make all; make

For good measure, also use "ocamlc -custom -ccopt -p ..." when linking
your application, to make sure "-p" is passed to the C compiler when
linking the custom runtime system.

> Secondly, I noticed that the interpreter was not compiled, by default, with
> -O on.

That is not true.  The Makefile in byterun/ adds the "-O" option itself.
Maybe a better place for that option would be in config/Makefile
itself.  But at any rate the bytecode interpreter is compiled with -O.

> By contrast, the threads library
> scheduler does have -O turned on, so it makes me think that gcc might do
> some optimizations that are not gc-safe.

Oh no, we don't let gcc mess with the GC... The GC interface is very
explicitely written down in the C code of the interpreter.  Any
optimization that would mess with the GC interface would be
semantically incorrect in a very big way.

Best regards,

- Xavier Leroy