[Python-ideas] Type Hinting - Performance booster ?

[Ludovic Gasc]

Hi Nick,

Thanks for your answer. I understand primary goal, I'm not completely naive
on this question: A long time ago, I used a lot Type Hinting with PHP 5.

Nevertheless, in Python community, you can find a lot of libraries to
improve performance based on types handling with different optimization
strategies  (numba, pypy, pythran, cython, llvm-py, shedskin...).
To my knowledge, you don't have the same number of libraries to do that
with another dynamic language.
It means that in Python community we have this problematic.

It's like with async pattern, in Python you have a plenty of libraries
(Twisted, eventlet, gevent, stackless, tornado...) and now, with AsyncIO,
the community should converge on it.

And yes, I understand that it's almost impossible to create a silver bullet
to improve automagically performance, but, as with my simple dev eyes, the
common pattern I see with pythran, cython... is the type handling.
They don't use only this strategy to improve performance, but it's the
biggest visible part in example codes I've seen.

Guido: " optimizers have been quite successful without type hints"  <=
Certainly, but instead of to loose time to try to guess the right data
structure, maybe it could be faster that the developer gives directly what
he wants.

To be honest, I'm a little bit tired to listen some bias like "Python is
slow", "not good for performance", "you must use C/Java/Erlang/Go..."
For me, Python has the right compromise to write quickly readable source
code and performance possibilities to speed up your code.

More we have primitives in CPython to build performant applications, more
it will be easier to convince people to use Python.

Regards.
--
Ludovic Gasc
On 21 Dec 2014 02:15, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

> On 21 December 2014 at 09:55, Ludovic Gasc <gmludo at gmail.com> wrote:
>
>> Hi,
>>
>> I'm only a simple Python developer, not a Type Hinting expert and I don't
>> know if you already discuss about that somewhere, but:
>>
>> With the future official support of Type Hinting in Python, is it means
>> that CPython could use this pieces of information to store variables with
>> more efficient data structures, not only check types ?
>>
>> It could possible to have better performance one day with Type Hinting
>> like you have with Cython (explicit types declaration) or PyPy (guessing
>> types) ?
>>
>
> The primary goals of the type hinting standardisation effort are improving
> program correctness (through enhanced static analysis) and API
> documentation (through clearer communication of expectations for input and
> output, both in the code, in documentation, and in IDEs). It should also
> allow the development of more advanced techniques for function signature
> based dispatch and other forms of structured pattern matching.
>
> From a performance perspective though, CPython already has a wide array of
> fast paths for particular builtin types - being able to communicate those
> assumptions more clearly won't automatically make it easier to speed them
> up further (or add more in a maintainable fashion). There's no
> *philosophical* objection to such changes (other than "simplicity is a
> virtue"), there's just a long track record of previous attempts like psyco
> and Unladen Swallow that make it clear that the problem is genuinely *hard*.
>
> There's also the fact that with both Numba and PyPy now supporting
> selective JIT acceleration of decorated functions within the context of a
> larger CPython application, as well as Cython's existing support for
> precompilation as a C extension, the pattern of profiling to find
> performance critical areas, and finding ways to optimise those, now seems
> well established. (Hence my suggestion the other day that we could likely
> use an introductory how to guide on performance profiling, which could also
> provide suggestions for optimisation tools to explore once the hot spots
> have been found).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141221/48032613/attachment.html>