Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I have doubts whether this can ever be good enough. For effective > coverage analysis, you have a to run an entire test-suite with > coverage enabled. Eg. for lilypond, the entire test-suite takes 5 > minutes on a 1.6ghz Core duo (single thread), when running > normally. That is a lot of Scheme code, and if for every frame-enter > or apply, a piece of user code is called, that will be an enormous > slowdown. Yes, that would still be a significant slowdown. What I meant is that there are roughly two approaches that can be taken to tackle such issues: (i) extend the C code base in ad hoc ways that allow the reduction of performance penalties in the specific use case that is addressed, and (ii) keep the C code base to a bare minimum but fast enough that specific mechanisms can be implemented atop, in Scheme. I agree that Guile has always favored the first approach, but I think it has a number of drawbacks in the long term (e.g., code complexity, lack of flexibility and hackability). > The real problem is not setting up the trap for calling, but rather > the fact that it > > - is called for every evaluation (for coverage, it needs to be done > only once) Right. > Of course, the patch that I posted is ad-hoc, because it hardcodes the > coverage analysis in eval.c. If it were to be included, I propose > something like > > (trap-set! 'memoize-symbol > record-coverage) > (trap-enable 'memoize-symbol) > > which would be possible with a generic, and quite minimal extension to > eval. Indeed, this looks less specific and more flexible. I'd personally prefer this approach. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
