[Openmcl-devel] Profiling

[Gary Byers]

Up until (IIRC) CHUD 4.5, Shark had the ability to read .spatch
files, which were simple text files that mapped an address range
to a symbolic name.  CHUD:METER produced these .spatch files, and
Shark's profiling info displayed things that looks like lisp function
names.

Support for .spatch files was quietly dropped, and I don't think that
any other way of naming arbitrary memory regions was introduced to
replace that support.

For a while, it was possible to replace newer versions of the CHUD
package with 4.5.  I don't know if it still is; it may still be possible
under Leopard but not Snow Leopard.

On Linux, we're able to save a heap image with ELF headers and symbolic
information prepended, and that made the heap image look enough like
an ELF library to fool the profiler (oprofile) into using that symbolic
information.  (As of a few years ago, oprofile was starting to offer
support for profiling JIT'ed code, and if that support still exists and
has matured, it might be preferable to use it in favor of the ELF tricks.)

I've tried a few times to do something analogous (to prepend a Mach-O header
and symbolic info to a heap image), but haven't had any luck in getting Shark
to use that information.  (I think that I've also seen suggestions that involve
using dSym files to provide symbolic information, but - assuming that one could
do that in general - it's not clear how dSym files could be used to describe
memory regions that contain dynamically generated code.)

Unless some better solution arises, you can do something crude and primitive
(like open the .spatch file in a text editor and use it to identify the 
otherwise anonymous memory regions that Shark displays, or save the profiling
info to a text file - if I remember correctly that you can do that - and use
the .spatch file to postprocess it.)  That's not nearly as nice as having
Shark identify functions for you.

There's some discussion of the issue at:

<http://lists.apple.com/archives/perfoptimization-dev/2009/Apr/msg00026.html>

There are all kinds of reasons that I can imagine for Apple not liking the
.spatch file format (it took a few seconds for Shark to parse what's essentially
a human-readable text file), but the general idea - being able to name memory
regions that contain dynamically generated code - seems like a good one, and it's
not clear from that discussion that the people who removed the functionality
had the same opinion.

On Sun, 26 Sep 2010, Willem Rein Oudshoorn wrote:

> Has anyone managed to use the chud-metering profiling in ccl?
>
> When I run it, it brings up Shark, with measurements, however the
> stacktraces do not show the function names, they are not recognized and
> printed by address.
>
> I have put in a
>
> (objc:defmethod (#/... )..
>
> which is set as an action for a button click code wrapped in chud:meter
> like this:
>
>  (chud:meter
>   (progn ...))
>
>
> Is this the wrong approach?
>
> Kind regards,
> Wim Oudshoorn.
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>