Optimizing Small Python Code

Avi Gross avigross at verizon.net
Thu Jun 24 20:21:36 EDT 2021


Barry,

 

I am not going to continue replying in this thread. I made my point and it
was focused after a while on the size of the CODE. Of course, the code can
be made ever smaller using gimmicks and yet run longer or use more memory or
CPU.

 

If you have control of a package with a short name like "x" for example, you
can write a function y() that builds in the code described or any variant
and your program becomes:

 

Import x

y()

 

and it would print out whatever you need.

 

If you can get the python interpreter to make that module standard, it can
be shorted more!

 

As mentioned, one suggested metric for how complex a program is, or maybe
how much information it contains, is the shortest program you can write to
generate the info. Something already compressed may not be easy to make
smaller. But the above idea does not care if the solution takes forever to
run as in if it uses lots of tiny re-usable functions and does lots of
recursion. 

 

Clearly, as has been pointed out, for many of the one-off programs people
write here, optimization is not necessarily worthwhile.  The program asked
for here actually has minimal purpose as it does one thing that could be
done in advance and replaced by a print statement. My "contribution" above
does look stupid but consider what it would mean if the program asked you to
print the first billion prime numbers. The program that simulated the output
would likely read in  huge file from disk and print it. The first part of
the I/O might be much faster if the data on disk was compressed and if it
could be uncompressed as it was being read and printed to the output, might
be lots faster and even use less memory. Clearly it would likely use more
CPU but far less than finding the first billion primes that hard way.

 

Final note is there is not much in the discussion that is really about
Python as much of the argument remains similar in many programming
languages.

 

So, I am done and will ignore this thread.

 

From: Barry Scott <barry at barrys-emacs.org> 
Sent: Thursday, June 24, 2021 3:12 PM
To: Avi Gross <avigross at verizon.net>
Cc: python-list at python.org
Subject: Re: Optimizing Small Python Code

 

 





On 24 Jun 2021, at 16:58, Avi Gross via Python-list <python-list at python.org
<mailto:python-list at python.org> > wrote:

 

Now a has a length of 53!

It now looks like this:

b'x\x9c3\xe4R\x00\x03\x03.#8\x0bB\x1br\x19c\x88(\x18q\x99p!q\xc1\x00\xa6\xd1
\x98\xcb\x14S\x03\x9a\n\x13.3\x82j \xb4\t\x94\x86\x99\t\x00\xdc\x87\x14\xb7'

So the shorter cheat program might now be:

 

The data is smaller, but at the cost of the code that knows how to
decompress it.

 

I'd expect that by using compression you have increased memory use as this

amount of data is far smaller than code to decompress it.

 

Barry

 



More information about the Python-list mailing list