[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: byte-opt.el addition - optimize list of compile-time constants

From: Stefan Monnier
Subject: Re: byte-opt.el addition - optimize list of compile-time constants
Date: Thu, 09 Dec 2004 00:13:17 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]