From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Colin Walters Newsgroups: gmane.emacs.devel Subject: Re: byte-compiler very slow Date: 21 Jul 2002 16:52:07 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1027284727.5453.5.camel@space-ghost> References: <3D39C79B.6020605@dponce.com> <200207212015.g6LKFgA00958@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1027284806 379 127.0.0.1 (21 Jul 2002 20:53:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Jul 2002 20:53:26 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17WNhk-000060-00 for ; Sun, 21 Jul 2002 22:53:24 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17WNvG-0007JQ-00 for ; Sun, 21 Jul 2002 23:07:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17WNhi-00058Z-00; Sun, 21 Jul 2002 16:53:22 -0400 Original-Received: from monk.debian.net ([216.185.54.61] helo=monk.verbum.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17WNgi-00056c-00 for ; Sun, 21 Jul 2002 16:52:20 -0400 Original-Received: from space-ghost.verbum.private (dhcp024-208-189-249.columbus.rr.com [24.208.189.249]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "space-ghost.verbum.org", Issuer "monk.verbum.org" (verified OK)) by monk.verbum.org (Postfix (Debian/GNU)) with ESMTP id 68B837400282 for ; Sun, 21 Jul 2002 16:52:19 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id 4D09C1103D5; Sun, 21 Jul 2002 16:52:08 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: <200207212015.g6LKFgA00958@aztec.santafe.edu> X-Mailer: Ximian Evolution 1.0.7 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5958 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5958 On Sun, 2002-07-21 at 16:15, Richard Stallman wrote: > I think this is an extremely nice feature. It is worth some slowdown, > byt 5x or 9x seems a bit much. It would be useful to do some > profiling on this. Does someeone want to do that? > > I have a feeling Colin Walters, who added that feature, may be on > vacation. Colin, if you are there, could you please speak up? Sorry, yes, semi-vacation; I've been trying to complete another free software project. > A simple optimization idea occurs to me. The byte compiler could > start processing a sexp in the old mode with the location tracking > feature turned off. If it encounters any sort of warning or error, it > could abort processing of that sexp and restart with the location > tracking feature turned on. This would give the same results but > all non-erroneous sexps would be processed faster. That would be a good way to handle it, but unfortunately in the current byte compiler implementation all sorts of side-effects happen while processing a sexp. It would be pretty tricky to unwind all of those. I think for the short term, we could make batch-byte-compile set a flag which reverts to the previous behavior of just printing line numbers. How does that sound? > The only case where this causes a problem would be when macros do very > weird things, such as if they their behavior depends on how many times > the macro is expanded. Perhaps it is an adequate solution to that > problem to say "Don't do that". There are already no guarantees on how many times a macro can be expanded, or exactly when it will be expanded, so I don't see a problem with this.