Re: frames / stacks / source? was Re: coverage/profiling

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <address@hidden> writes:

> Unfortunately, this is way too slow.
>
> **
> address@hidden lilypond]$ time lilypond input/example-1
> GNU LilyPond 2.11.10
>
> Hangup
>
> real    0m2.534s
> user    0m2.456s
> sys     0m0.063s
>
>
> address@hidden lilypond]$ time lilypond -dcoverage input/example-1
> GNU LilyPond 2.11.10
>
> Hangup
>
> real    1m22.184s
> user    1m19.808s
> sys     0m0.235s
> **

Is this with just the `enter-frame' trap enabled (with corresponding
handler), or are there any additional traps?  What do(es) the handler(s)
do?

Besides, it _really_ doesn't work here (see backtrace in my previous
post):

  $ guile-1.8.0 
  guile> (trap-set! enter-frame-handler (lambda args (format #f "args: ~a~%" 
args)))
  (exit-frame-handler #f apply-frame-handler #f enter-frame-handler #<procedure 
#f args> traps)
  guile> (trap-enable 'enter-frame)
  Segmentation fault (core dumped)

Did I miss something, or did I mess up with my Guile?

> Perhaps the better option is to somehow instrument the code such that
> memoization of an expression records the coverage. Then we won't get 
> execution counts, but it should be almost as fast as normal running.

If such instrumentation were to be added to `eval', we'd have to make
sure that it gets commented out when we don't want it (just like
debugging code is pruned from `ceval ()').

Thanks,
Ludovic.