* Code coverage reports for Scheme
@ 2010-04-21 21:59 Ludovic Courtès
2010-04-22 11:31 ` Andy Wingo
2010-05-07 12:11 ` Ludovic Courtès
0 siblings, 2 replies; 3+ messages in thread
From: Ludovic Courtès @ 2010-04-21 21:59 UTC (permalink / raw)
To: guile-devel
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Hello!
Here’s a code coverage report for Guile’s Scheme code:
http://www.fdn.fr/~lcourtes/software/guile/guile.lcov/
So here’s the idea: pick the red box of your choice and make it so that
next time it’ll be bright green. :-)
The report was generated using LCOV on data produced using (system vm
coverage) in the ‘wip-coverage’ branch, like this:
$ ./check-guile --coverage
;; wait...
$ genhtml -o guile.lcov guile.info
(I cheated, though: I removed poe.test because of bug #29616 and
statprof.test because it was taking too long.)
It’s slow but manageable: 69mn on my 1.2 GHz laptop vs. ~1mn30s for a
non-coverage run, i.e., 46 times slower.
To achieve this high level of performance, vm_dispatch_hook () allocates
frame objects on the C stack instead of on the heap. Thus the lifetime
of frame objects is limited to the hook invocation. I think it’s a
necessary evil.
Another option would have been to not use frame objects at all and pass
hooks the FP, IP, etc. However, hooks would have had to provide in
Scheme the functionality provided in C by frame objects, such as
‘frame-procedure’, the arithmetic in ‘frame-instruction-pointer’, etc.
In the end that would probably have been slower.
I think there’s room for optimization on the path to hook invocation,
but that’s probably not a high priority.
I’ll merge it when the “absolute path in .go” issue has settled and when
I’ve written unit tests.
Comments welcome!
Thanks,
Ludo’.
PS: Thanks to Andy for his tips and tricks to optimize the collection hook!
PPS: Initially I envisioned a hook written in a purely functional way,
using delimited continuations to suspend/resume its data gathering
job and a functional data structure to store that data. But I
realized that vlist-based hash lists are unsuitable for the kind of
2-level map needed here (we map procedures to a map from IP to
execution counts; updating execution counts would be very costly.)
Thoughts?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-05-07 12:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-21 21:59 Code coverage reports for Scheme Ludovic Courtès
2010-04-22 11:31 ` Andy Wingo
2010-05-07 12:11 ` Ludovic Courtès
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).