This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Use PEP 590 vectorcall to speed up GenericAlias.
Type: performance Stage: resolved
Components: Interpreter Core Versions: Python 3.9
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: corona10 Nosy List: corona10, gvanrossum, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2020-04-23 02:48 by corona10, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
bench_generic_alias.py corona10, 2020-04-23 02:48
Pull Requests
URL Status Linked Edit
PR 19677 closed corona10, 2020-04-23 12:56
Messages (8)
msg367074 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-04-23 02:48
Since PEP 560 was approved,
The following syntax has become available. 

from queue import Queue
v = Queue[int]

It's a very shiny feature.
Given the direction of programming language, it's probably a very useful feature that users will use very often in the near future.

When I looked at Object/geneticiasobject.c, the current implementation is a very good condition for using the vectorcall proposed by PEP590 .

The benchmarks are as follows.
So I suggest using vectorcall in GenericAlias.

if the suggestion is accepted, I 'd like to summit the patch :)


+--------------------+----------------------+-----------------------------+
| Benchmark          | master-generic-alias | proposed-generic-alias      |
+====================+======================+=============================+
| bench GenericAlias | 143 ns               | 111 ns: 1.29x faster (-22%) |
+--------------------+----------------------+-----------------------------+
msg367103 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-23 12:12
> if the suggestion is accepted, I 'd like to summit the patch :)

Can you propose a PR, so I can have a look at the implementation?
msg367104 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-04-23 12:19
> Can you propose a PR, so I can have a look at the implementation?

Got it :), I will upload it soon.
msg367106 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-04-23 12:28
I have doubts that GenericAlias instances are created in mass in tight loops. Do you have any realistic example which would benefit from speeding up creation of GenericAlias instances?
msg367107 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-04-23 13:01
> Do you have any realistic example which would benefit from speeding up the creation of GenericAlias instances?

Hmm I did not find loop tightly calling case, but
for example, this kinds of usage are very often.

def create_q(l: list[int]) -> Queue[int]:
    q = Queue[int]()
    for e in l:
        q.put(e)
    return q

a = create_q([1,2,3,4,5])

In this code, GenericAlias is called 2 times for function declare and function call.

It's true that GenericAlias ​​has a small portion in this scenario,
but wouldn't it be worth it if we could optimize itself to a few lines of code?
msg367108 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-04-23 13:14
And how much faster has your example become?
msg367109 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-04-23 13:31
> And how much faster has your example become?

For function declaration, 5% enhancement,
the function call does not show difference because the GenericAlias is not big portion on calling.

+--------------------+------------------------+----------------------------+
| Benchmark          | master-generic-alias-1 | bpo-40369-generic-alias-1  |
+====================+========================+============================+
| bench GenericAlias | 420 ns                 | 399 ns: 1.05x faster (-5%) |
+--------------------+------------------------+----------------------------+
msg367128 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-04-23 16:08
Just for the record,

https://github.com/python/cpython/pull/19677#discussion_r413894982

guido left an opinion that the caching approach might be more proper.
So I 'd like to suggest open a new issue for caching. :)
History
Date User Action Args
2022-04-11 14:59:29adminsetgithub: 84549
2020-04-23 16:27:29corona10setstatus: open -> closed
resolution: rejected
stage: patch review -> resolved
2020-04-23 16:08:50corona10setmessages: + msg367128
2020-04-23 13:31:35corona10setmessages: + msg367109
2020-04-23 13:14:57serhiy.storchakasetmessages: + msg367108
2020-04-23 13:01:40corona10setmessages: + msg367107
2020-04-23 12:56:43corona10setkeywords: + patch
stage: patch review
pull_requests: + pull_request19000
2020-04-23 12:28:10serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg367106
2020-04-23 12:19:48corona10setmessages: + msg367104
2020-04-23 12:12:27vstinnersetmessages: + msg367103
2020-04-23 02:52:53corona10setassignee: corona10
type: performance
2020-04-23 02:48:54corona10create