From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] experimental lookupcar based coverage testing. Date: Fri, 19 Jan 2007 14:49:22 +0100 Message-ID: <45B0CC62.7020705@xs4all.nl> References: <45AFCEFD.5030203@xs4all.nl> <87lkjz40zc.fsf@laas.fr> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1169214620 31669 80.91.229.12 (19 Jan 2007 13:50:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2007 13:50:20 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 19 14:50:17 2007 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.50) id 1H7u8E-0001Mu-Pz for guile-devel@m.gmane.org; Fri, 19 Jan 2007 14:50:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H7u8E-00020t-Bl for guile-devel@m.gmane.org; Fri, 19 Jan 2007 08:50:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H7u7O-0001ZY-Ho for guile-devel@gnu.org; Fri, 19 Jan 2007 08:49:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H7u7M-0001YK-JD for guile-devel@gnu.org; Fri, 19 Jan 2007 08:49:21 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H7u7L-0001Xx-MS for guile-devel@gnu.org; Fri, 19 Jan 2007 08:49:19 -0500 Original-Received: from [194.109.24.25] (helo=smtp-vbr5.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H7u7K-0005xS-3e for guile-devel@gnu.org; Fri, 19 Jan 2007 08:49:18 -0500 Original-Received: from [192.168.123.187] (muurbloem.xs4all.nl [213.84.26.127]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0JDnGoH016517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jan 2007 14:49:17 +0100 (CET) (envelope-from hanwen@xs4all.nl) User-Agent: Thunderbird 1.5.0.9 (X11/20061219) Original-Newsgroups: gmane.lisp.guile.devel Original-To: hanwen@xs4all.nl, guile-devel@gnu.org In-Reply-To: <87lkjz40zc.fsf@laas.fr> X-Virus-Scanned: by XS4ALL Virus Scanner X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-vbr5.xs4all.nl id l0JDnGoH016517 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:6455 Archived-At: Ludovic Court=E8s escreveu: >> See attached patch. This still has rough edges. For some reason, I >> don't catch the memoization of display to #. >=20 > Overall, as Kevin suggested, I'd be more in favor of using the existing > trap mechanism (possibly extending it if it doesn't provide enough > information to trap handlers). However, as you already said, the trap > mechanism is damn slow. I guess it is mostly slow because the evaluato= r > is slow, but the trap mechanism itself may be optimizable, too. >=20 > If you look at `ENTER_APPLY' around line 3025, it makes at least two > function calls: `scm_make_debugobj ()' and `scm_call_3 ()'. The former > is a one-line function and should really be inlined. The latter > introduces unnecessary overhead since it ends up calling `SCM_APPLY ()' > which in turns necessarily jumps to the `scm_tcs_closures' case since > trap handlers are always closures. Thus, at the very least, > `scm_call_3 ()' should be replaced by `SCM_APPLY ()'. >=20 > These small optimizations would certainly be worthwhile, although > perhaps not sufficient. 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. The real problem is not setting up the trap for calling, but rather=20 the fact that it=20 - is called for every evaluation (for coverage, it needs to be done only once) - is user-code, ie. something as simple as (car x) (which is just a couple of instructions) will expand into (begin (vector-set!=20 (hash-ref coverage-table (source-property (frame-source (last-frame continuation)) 'filename)) (source-property (frame-source (last-frame continuation)) 'line) #t) (car x)) which would likely be a couple of orders of magnitude slower. =20 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. However, I'd like some feedback on the approach before reworking the ad-hoc patch into a real one. --=20 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel