Laura Creighton <l...@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 -- https://mail.python.org/mailman/listinfo/python-list