From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] experimental lookupcar based coverage testing. Date: Fri, 19 Jan 2007 17:05:32 +0100 Organization: LAAS-CNRS Message-ID: <87lkjzypbn.fsf@laas.fr> References: <45AFCEFD.5030203@xs4all.nl> <87lkjz40zc.fsf@laas.fr> <45B0CC62.7020705@xs4all.nl> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1169222746 31250 80.91.229.12 (19 Jan 2007 16:05:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2007 16:05:46 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 19 17:05:43 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 1H7wFG-0002x7-68 for guile-devel@m.gmane.org; Fri, 19 Jan 2007 17:05:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H7wFF-0005kT-Qy for guile-devel@m.gmane.org; Fri, 19 Jan 2007 11:05:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H7wFA-0005jp-Vn for guile-devel@gnu.org; Fri, 19 Jan 2007 11:05:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H7wF8-0005i7-Do for guile-devel@gnu.org; Fri, 19 Jan 2007 11:05:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H7wF7-0005hh-Q7 for guile-devel@gnu.org; Fri, 19 Jan 2007 11:05:30 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1H7wF6-0007jy-F7 for guile-devel@gnu.org; Fri, 19 Jan 2007 11:05:28 -0500 Original-Received: from messiaen.laas.fr (messiaen [IPv6:2001:660:6602:0:230:65ff:fed4:9d20]) by laas.laas.fr (8.13.8/8.13.8) with SMTP id l0JG5P2K027259; Fri, 19 Jan 2007 17:05:25 +0100 (MET) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Fri, 19 Jan 2007 17:05:32 +0100 Original-To: hanwen@xs4all.nl X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 30 =?iso-8859-1?Q?Niv=F4se?= an 215 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: hanwen@xs4all.nl, guile-devel@gnu.org In-Reply-To: <45B0CC62.7020705@xs4all.nl> (Han-Wen Nienhuys's message of "Fri, 19 Jan 2007 14:49:22 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: -0.001 () NO_RELAYS X-Scanned-By: MIMEDefang at CNRS-LAAS on IPv6:2001:660:6602::2 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:6458 Archived-At: Hi, Han-Wen Nienhuys 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