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] |
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)