[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] experimental lookupcar based coverage testing.
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] experimental lookupcar based coverage testing. |
Date: |
Fri, 19 Jan 2007 17:05:32 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Hi,
Han-Wen Nienhuys <address@hidden> 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.