[Python-ideas] Disabling optimizations
Ned Batchelder
ned at nedbatchelder.com
Fri May 23 13:59:48 CEST 2014
On 5/23/14 5:57 AM, Antoine Pitrou wrote:
> On Fri, 23 May 2014 07:28:32 +0200
> Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> As I already proposed, we could get rid of .pyo files all together and only
>>> write unoptimised .pyc files, and then apply the optimisations at load time
>>> based on the current interpreter config. I think that would give us a good
>>> tradeoff between fast (precompiled) code loading and differing requirements
>>> on byte code optimisations.
>> Stefan Krah already proposed -Os (optimise for space) for the cases where
>> you want to reduce the size of the byte code file, e.g. by removing doc
>> strings. That could become the next .pyo file. Although it's unclear to me
>> why you would do that, instead of just compressing them.
> People who are really short on disk space (embedded devs?) probably do
> both: first strip docstrings and friends, then compress.
>
> For the same reason, optimizing in-memory would be detrimental:
> optimizations can usually reduce the size of pyc files.
>
> (besides, optimizing at compile-time allows us to do more costly
> optimizations without caring *too much* about their overhead)
Optimizing at compile time also lets you do optimizations that are not
bytecode->bytecode transformations. Most of the recent discussion about
new optimizations is focused on AST manipulations. Although I started
this discussion with the word "peephole", those types of optimizations
also affect the source->bytecode mapping, and should be controlled by
the levers we're discussing.
--Ned.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
More information about the Python-ideas
mailing list