From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: byte-opt.el addition - optimize list of compile-time constants Date: Thu, 09 Dec 2004 00:13:17 -0500 Message-ID: <87mzwooy7n.fsf-monnier+emacs@gnu.org> References: <87u0qxgn65.fsf@codesourcery.com> <878y88hazn.fsf@codesourcery.com> <87llc8tnjr.fsf@codesourcery.com> <878y88s6po.fsf-monnier+emacs@gnu.org> <874qiwqncp.fsf@codesourcery.com> <87llc8qlcb.fsf-monnier+emacs@gnu.org> <87zn0op5dj.fsf@codesourcery.com> <87brd4qeoq.fsf-monnier+emacs@gnu.org> <87is7coyt5.fsf@codesourcery.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1102569238 7940 80.91.229.6 (9 Dec 2004 05:13:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2004 05:13:58 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 09 06:13: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 1CcGcj-0002Sl-00 for ; Thu, 09 Dec 2004 06:13:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CcGmc-00034z-IO for ged-emacs-devel@m.gmane.org; Thu, 09 Dec 2004 00:24:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CcGmN-00030R-3H for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:23:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CcGmM-00030F-J8 for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:23:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CcGmM-000301-DG for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:23:50 -0500 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CcGc7-0006KS-QO for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:13:16 -0500 Original-Received: from alfajor ([67.71.27.115]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041209051314.DTZA25979.tomts25-srv.bellnexxia.net@alfajor>; Thu, 9 Dec 2004 00:13:14 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id ED75FD7318; Thu, 9 Dec 2004 00:13:17 -0500 (EST) Original-To: Zack Weinberg In-Reply-To: <87is7coyt5.fsf@codesourcery.com> (Zack Weinberg's message of "Wed, 08 Dec 2004 20:55:34 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30924 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30924 >> How often is this code executed? It doesn't smell like code you're using >> inside a loop, so efficiency is really completely irrelevant: the extra >> byte-codes and consing you get with backquotes is really a total non-issue. > The outer code is executed only once when the library is loaded. The > embedded lambda *is* executed in a loop, which is why I care about it > getting compiled. I understand that part, I'm only talking about the use of backquote to get the lambda to be compiled at the cost of a few byte-codes and conses. > As I said in the original message, it is easy to > come up with cases where the extra byte-codes and consing from > backquotes *are* performance-relevant, but given how badly it breaks > things to enable that optimization, I'm prepared to drop that (unless > someone wants to help me debug weird byte-compiler crashes). The issue is not "can you come up with an example where it matters". If you start from such a premise, code optimization is simply impossible because there's always some example you can come up with that you still haven't compiled right and for which all the optimizations you've written turn into pessimizations. Optimizers have to be pragmatic and start with "which *existing* code *needs* to be optimized". Your original example is *existing*, but doesn't *need* to be optimized since it's not executed repeatedly. Your hypothetical pathological case may *need* to be optimized but as long as it's not *existing*, it's irrelevant. Stefan