Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Unfortunately, this is way too slow. > > ** > [EMAIL PROTECTED] lilypond]$ time lilypond input/example-1 > GNU LilyPond 2.11.10 > > Hangup > > real 0m2.534s > user 0m2.456s > sys 0m0.063s > > > [EMAIL PROTECTED] 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. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
