Re: [PATCH] experimental lookupcar based coverage testing.

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> 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