This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

profiling support


I am about to get a serious for some usefull profiling support, but
before jumping off the cliff, I thought I would leave this last
message to the world, sketching my plans :-) Note that these are
necessarily rough and preliminary.

All comments and hints are welcome.

Having done some experiments with scheme level profiling, I have come
to the conclusion that serious profiling needs support from the
evaluator. Depending on the C compiler for C level profiling also
usually is useless since I typically see 80% of the time consumed by
eval (30%) and garbage collection (50%), even for programs compiled by
hobbit. So we need something that can monitor the movements on the
(scheme) stack and that includes allocation.

USER LEVEL:

The user level interface consists of two new debug options, `profile'
and `profile-mode' and two new functions, profile-report and
profile-reset.

Profiling is turned on by `(debug-enable 'profile)', the results are
listed using `profile-report' and `profile-reset' will clear the
profile results database. Profiling will only work with the debugging
allocator.

The profile mode determines the amount of data gathered during
profiling, with the following intended interpretation:

	   level 1: call count
	   level 2: real time spent
	   level 3: bytes allocated
	   level 4: cells allocated
	   level 5: call graph recordings

Some choice are possible here, such as to let level 0 signify
profiling off, letting call graphs be a separate option or to always
record bytes and cells together. One could also interpret the mode as
a bit mask rather than a level indicator providing full flexibility.

DETAILS

Data is collected with each procedure object. A special slot is
allocated for storage and in this a vector, whose size matches the
profile mode and is allocated as necessary, is stored holding the
data. This way, no more storage is allocated during profiling than
actually necessary and one can even get rid of it later if desired.

The profiling code also maintains a hit list saving all procedure
objects encountered during profile. Since the data is distributed
along with each procedure, we need some convenient way to know which
objects to investigate during reporting or resetting.

Call graphs are more complicated. Currently, my plan is to save every
single applications on a (huge) stack detailing procedure and stack
depth (on the evalution stack). I think this should be enough to
regenerate the call graph.

Data is gathered by at the beginning of each application (ie. call to
scm_deval) to note the value of the clocks we are currently
tracking. At the end of the application the difference is noted and
added to the slot of the procedure.

The real time clock is already supported, but we need also memory
clocks, ie. variables incremented at relevant spots each cells and/or
bytes are allocated but *not* decreased during gc.


---------------------------+--------------------------------------------------
Christian Lynbech          | Telebit Communications A/S                       
Fax:   +45 8628 8186       | Fabrik 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28  | email: chl@tbit.dk --- URL: http://www.telebit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)