[Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

R. David Murray rdmurray at bitdance.com
Sun Nov 17 18:50:13 CET 2013


On Sun, 17 Nov 2013 17:14:38 +0100, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2013/11/16 Maciej Fijalkowski <fijall at gmail.com>:
> > Can I see some writeup how -OO benefit embedded devices?
> 
> You get smaller .pyc files. In an embedded device, the whole OS may be
> written in a small memory, something like 64 MB or smaller. Removing
> doctrings help to fit in 64 MB.
> 
> I don't know if dropping "assert" statements is required on embedded device.

I've worked on a project (mobile platform) where both of these
were true.  Did we gain much by dropping asserts?  As with Steve's
case, no one bothered to measure, but it was a no-brainer win so we did it.
Especially since we really needed to kill the docstrings to save memory.
(Killing linecache was an even bigger win on the memory side).

I unfortunately don't remember how much difference removing docstrings
made in the process size, but I'm pretty sure it was more than a MB,
and on a device with no swap in a process that must be running all the
time, even 1MB makes a significant difference.

On the assert side, if there hadn't been an option to remove the asserts,
I'm sure that the call would have come down to manually remove all the
asserts for production, which would have been a pain.  In that case they
*might* have measured, but since you'd have to do the removal work to
do the measurement, they'd probably not have bothered.

I'd say that if someone wants to drop assert removal, they'd need
to prove that it *didn't* result in a speedup, which would be pretty
hard considering that the checks covered by assert/if __debug__ can be
arbitrarily complex :)

But...yes, it would have been nice to have been able to remove docstrings
and asserts *separately*.  We might have measured the delta and decided to
keep them in the beta in that case, since the asserts did catch some bugs.

--David


More information about the Python-Dev mailing list