From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Code coverage reports for Scheme Date: Wed, 21 Apr 2010 23:59:56 +0200 Message-ID: <878w8gv543.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1271887237 22294 80.91.229.12 (21 Apr 2010 22:00:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Apr 2010 22:00:37 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Apr 22 00:00:36 2010 connect(): No such file or directory Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O4hyD-0004Yj-RC for guile-devel@m.gmane.org; Thu, 22 Apr 2010 00:00:34 +0200 Original-Received: from localhost ([127.0.0.1]:49672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4hyC-00080R-QW for guile-devel@m.gmane.org; Wed, 21 Apr 2010 18:00:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4hy4-0007yK-1t for guile-devel@gnu.org; Wed, 21 Apr 2010 18:00:24 -0400 Original-Received: from [140.186.70.92] (port=60902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4hy2-0007xU-Hc for guile-devel@gnu.org; Wed, 21 Apr 2010 18:00:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4hy0-0005Cr-BZ for guile-devel@gnu.org; Wed, 21 Apr 2010 18:00:22 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:43493) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4hy0-0005CN-1k for guile-devel@gnu.org; Wed, 21 Apr 2010 18:00:20 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O4hxw-0004Pa-2s for guile-devel@gnu.org; Thu, 22 Apr 2010 00:00:16 +0200 Original-Received: from acces.bordeaux.inria.fr ([193.50.110.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2010 00:00:16 +0200 Original-Received: from ludo by acces.bordeaux.inria.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2010 00:00:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 74 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: acces.bordeaux.inria.fr User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 2 =?iso-8859-1?Q?Flor=E9al?= an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Cancel-Lock: sha1:0QIJlycABX11kV7FXmR71yJ98/g= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10281 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! Here=E2=80=99s a code coverage report for Guile=E2=80=99s Scheme code: http://www.fdn.fr/~lcourtes/software/guile/guile.lcov/ So here=E2=80=99s the idea: pick the red box of your choice and make it so = that next time it=E2=80=99ll be bright green. :-) The report was generated using LCOV on data produced using (system vm coverage) in the =E2=80=98wip-coverage=E2=80=99 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=E2=80=99s 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=E2=80=99s 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 =E2=80=98frame-procedure=E2=80=99, the arithmetic in =E2=80=98frame-instruc= tion-pointer=E2=80=99, etc. In the end that would probably have been slower. I think there=E2=80=99s room for optimization on the path to hook invocatio= n, but that=E2=80=99s probably not a high priority. I=E2=80=99ll merge it when the =E2=80=9Cabsolute path in .go=E2=80=9D issue= has settled and when I=E2=80=99ve written unit tests. Comments welcome! Thanks, Ludo=E2=80=99. 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? --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkvPdWEACgkQd92V4upS7PR9qQCeIhQiayF0PJ78Po2O8XCpfCvx +JsAmweKlt1RA/rnIgmtkuzNU67A9xhG =sQqF -----END PGP SIGNATURE----- --=-=-=--