Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Ben Finney <ben+python@benfinney.id.au>
Newsgroups: comp.lang.python
Subject: Re: Question about math.pi is mutable
Date: Tue, 10 Nov 2015 10:21:05 +1100
Lines: 45
Message-ID: <mailman.192.1447111281.16136.python-list@python.org>
References: <n1kshk$brb$1@dont-email.me> <563eba85$0$1611$c3e8da3$5496439d@news.astraweb.com> <n1n8mc$33l$1@dont-email.me> <87ziyowy83.fsf@elektro.pacujo.net> <n1nb0f$atn$1@dont-email.me> <mailman.135.1446998410.16136.python-list@python.org> <n1o25a$3s3$1@dont-email.me> <mailman.142.1447005691.16136.python-list@python.org> <n1o5sl$joc$1@dont-email.me> <mailman.152.1447024427.16136.python-list@python.org> <n1on71$san$1@dont-email.me> <8537wghwjb.fsf@benfinney.id.au> <CAPTjJmo=4p3DnvcLY_whdzaiy1t-sTyok20U9M0nQsNCg9_E=Q@mail.gmail.com> <85y4e8ggrj.fsf@benfinney.id.au> <CAPTjJmqaTQy397xgSjQsC2Bu8mxDQTvGsryp0e6nDk6Le688=A@mail.gmail.com> <85twowgfm6.fsf@benfinney.id.au> <CAPTjJmq--XE006MzxNe_3d_rmOP9GYxM_AxMF7Nh3d3RQbBx4g@mail.gmail.com> <mailman.160.1447031104.16136.python-list@python.org> <564081e7$0$1592$c3e8da3$5496439d@news.astraweb.com> <85fv0fgdnf.fsf@benfinney.id.au> <201511092007.tA9K7vbW000701@fido.openend.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cancel-Lock: sha1:GGQW3Peh80z5FMz9HvvhWAEAjyc=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
Precedence: list
Xref: csiph.com comp.lang.python:98561

Laura Creighton <lac@openend.se> writes:

> In a message of Tue, 10 Nov 2015 06:45:40 +1100, Ben Finney writes:
> >So the remaining space of code that is safe for the proposed
> >optimisation is trivially small. Why bother with such optimisations, if
> >the only code that can benefit is *already* small and simple?
>
> You have things backwards.
> The reason that you want to optimise this is that it is small, simple, 
> and slow_slow_slow_slow_slow.
>
> It is the things that are complicated and large that usually aren't
> worth optimising. You don't call them often enough for it to be worth
> it to optimise them.

I appreciate you making the the distinction explicit between a small and
simple *code unit* (e.g. an small, simple, often-called function),
versus a large and complex *code unit* (e.g. a large, complex,
infrequently-called class definition).

I'm pointing out an orthogonal issue: The only code to which the
proposed optimisation could apply is *module-level* (infrequently
called) code, which *has no complications* (i.e. not a code unit).

The simplicitly of the small section of code is not the issue; the
dynamism of the entire program is what negates the applicability of the
optimisation.

If the simple, predictable-by-the-compiler segment of code were actually
isolated in a simple unit, then yes, such optimisations might be
considered. But, as already discussed, the optimisation is not intended
to apply to such code units. So that is moot in this case.

Instead, we're talking about optimisations proposed *only* for
module-level code (i.e. not isolated); and what negates their
applicability is *any* dynamism (i.e. not simple), anywhere in the
program (i.e. not a code unit). The space of applicability for the
proposed optimisation shrinks to irrelevance, AFAICT.

-- 
 \        “If the arguments in favor of atheism upset you, explain why |
  `\        they’re wrong. If you can’t do that, that’s your problem.” |
_o__)                                     —Amanda Marcotte, 2015-02-13 |
Ben Finney