[Python-Dev] Investigating Python memory footprint of one real Web application

[Lukasz Langa]

> On Jan 23, 2017, at 12:10 PM, Brett Cannon <brett at python.org> wrote:
> 
> 
> 
> On Mon, 23 Jan 2017 at 04:27 INADA Naoki <songofacandy at gmail.com <mailto:songofacandy at gmail.com>> wrote:
> On Mon, Jan 23, 2017 at 8:33 PM, Victor Stinner
> <victor.stinner at gmail.com <mailto:victor.stinner at gmail.com>> wrote:
> > 2017-01-23 12:25 GMT+01:00 INADA Naoki <songofacandy at gmail.com <mailto:songofacandy at gmail.com>>:
> >> I gave advice to use 'List[User]' instead of List[User] to the team of
> >> the project,
> >> if the team think RAM usage or boot speed is important.
> >
> > I would prefer a Python option (ex: "-o noannotation" command line
> > option) to opt-out annotations rather than having to write annotations
> > in strings, which is IMHO more "ugly".
> 
> So basically the equivalent of -OO for docstrings? Maybe this can be the final motivator for some of us to come up with a design to generalize -O or something as it keeps coming up.

Yes, please. We've talked about generalizing this for years now. FWIW, I know of projects that run with -OO for the memory wins stemming from docstrings and had to codemod assert statements into a "prod_assert" function call to achieve this. If you think docstrings aren't that much, multiply this by a few hundred processes on a box and it ends up being a substantial win to strip them out.

> >
> > Victor
> 
> Personally speaking, I hope annotations are just static hint, and
> makes zero overhead at runtime.
> (startup time, memory consumption, and execution speed).
> 
> Local variable annotations are nothing but info in the AST. Parameter annotations and class annotations are stored on their respective objects so there's memory usage from that and the construction of them at object creation time, but that's it (e.g. the cost of creating func.__annotations__ when the function object is created is all you pay for performance-wise). And using strings will make those introspective attributes difficult to use, hence why I don't think people have said to do that everywhere.

I suggested making all annotations just strings at runtime and PEP 484 still lists this as a possible course for the future. So far Guido blocked this on a legitimate question: how much do type hints actually cost? Nobody knows yet, the biggest annotated codebase is at Dropbox and this is using comments (so no runtime cost).

>  
> Anyway, many users are starting to use typing, for code completion or
> static checking.
> And very few user noticed it affects to performance of `isinstance(x,
> collections.Sequence)`.
> Python 3.7 may be too slow to help them.
> Can't we skip abc registration of typing.List[MyClass] completely?
> 
> I'm sorry if it's silly idea.  I don't know about background of
> current typing.py design. And I
> don't use abc much too.
> 
> Since isinstance() checks are expected to be rare I don't think anyone has worried too much about the performance beyond the initial work to introduce ABCs and __instancecheck__.

Similar to the above, I would advise against crippling functionality unless we prove this is affecting performance in a significant way.

- Ł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170123/9283c330/attachment.html>