> 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