From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: byte-code optimizations Date: Tue, 21 Sep 2004 14:31:28 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409181152.15364.pogonyshev@gmx.net> <200409191412.50820.pogonyshev@gmx.net> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1095791578 17241 80.91.229.6 (21 Sep 2004 18:32:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Sep 2004 18:32:58 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 21 20:32:54 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C9pRd-0001ch-00 for ; Tue, 21 Sep 2004 20:32:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9pXZ-0006JM-VK for ged-emacs-devel@m.gmane.org; Tue, 21 Sep 2004 14:39:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9pWW-0005iW-NS for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:37:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9pWU-0005gt-2U for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:37:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9pWS-0005gA-Uf for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:37:53 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9pQI-0004DF-KA for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:31:30 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1C9pQG-0005KW-T2; Tue, 21 Sep 2004 14:31:30 -0400 Original-To: Paul Pogonyshev In-reply-to: <200409191412.50820.pogonyshev@gmx.net> (message from Paul Pogonyshev on Sun, 19 Sep 2004 14:15:11 -0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27378 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27378 However, we (actually Stefan) need to decide whether we want to try optimizing unbinds without visible bindings. I.e. I'm optimizing varbind-X ... unbind-N --> discard ... unbind-(N-1) while Stefan suggests a more general ... unbind-1 --> unbind-1 ... which is then followuped by other (existing) optimizations. The way to decide this is to look at what the results would be in various cases. Simply doing the unbind-1 earlier is not a significant improvement; it does not make the code smaller or faster. As far as I can see, the only way it achieves a benefit is if it leads to eliminating the unbind-1. That would only happen if Stefan's optimization moves the unbind-1 back to right after a varbind, right? If so is optimization is indirectly equivalent to yours. I can see one other case where Stefan's optimization might make a difference. If we install your tail-jumping optimization, Stefan's optimization might produce more opportunities to do tail-jumping, or it might ruin some opportunities to do tail-jumping. But I think that effect will be too small to matter anyway. Unless I have missed some point here, I think your version of the optimization is the better of the two (all else being equal), because it gets directly to the desired result instead of requiring it to be done in two steps. Some comments on details of your code: +(put 't 'binding-is-magic t) +(put 'nil 'binding-is-magic t) That is unnecessary; you can't bind nil or t, +(put 'debug-on-next-call 'binding-is-magic t) That is unnecessary, since a function call would never be safe to do this optimization over, +(defconst byte-compile-side-effect-free-dynamically-safe-ops + '(;; Same as `byte-compile-side-effect-free-ops' but without + ;; `byte-varref', `byte-symbol-value' and certain editing + ;; primitives. Why exclude byte-symbol-value? After you deal with those little points, I'd like your code to be installed. However, there is still the question of whether we should change the standard defsubst to work the way defsubst* does.