Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

bpo-29548: Fix some inefficient call API usage#97

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
methane merged 4 commits intopython:masterfrommethane:fix-call-usage
Feb 16, 2017

Conversation

methane
Copy link
Member

@methanemethane commentedFeb 14, 2017
edited
Loading

Whilebpo-29548, some inefficientPyEval_Call*() usage are found.
This is spin off pull request for fixing them.

  • Use_PyObject_CallNoArg() when there are no arguments.
  • UsePyObject_CallMethod instead of manually callingPy_BuildValue(). (temporary tuple may be skipped)

PyTuple_SetItem(args, 1, op2);
if ((result = PyEval_CallObject(func, args)) == NULL)
PyObject *args[] = {result, op2};
if ((result = _PyObject_FastCall(func, args, 2)) == NULL) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Would you mind to move the assignment out of the if() please? "result = ...; if (result == NULL) ...".

for (;;) {
PyObject *op2;

if (args->ob_refcnt > 1) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I expect a ltitle slowdown if the function doesn't support fastcall. For example, a Python object with acall() method.

Can you please try to run a quick benchmark on the following two cases:

  • function supporting FASTCALL, like a builtin function
  • function not supporting FASTCALL

In general, I'm in favor of removing such hack, since playing with reference count can lead to complex and annoying bugs. But I would prefer to first see the cost on performances.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

# operator.add is FASTCALL C function$ ./python -m perf timeit --compare-to $HOME/work/python/cpython/python -s  'L = [0]*10000' -s 'import functools, operator' -- 'functools.reduce(operator.add, L)'/home/inada-n/work/python/cpython/python: ..................... 498 us +- 3 us/home/inada-n/work/python/fix-call-usage/python: ..................... 412 us +- 8 usMedian +- std dev: [/home/inada-n/work/python/cpython/python] 498 us +- 3 us -> [/home/inada-n/work/python/fix-call-usage/python] 412 us +- 8 us: 1.21x faster (-17%)# lambda is Python function (supports FASTCALL)$ ./python -m perf timeit --compare-to $HOME/work/python/cpython/python -s  'L = [0]*10000' -s 'import functools' -- 'functools.reduce(lambda x,y: x, L)'/home/inada-n/work/python/cpython/python: ..................... 831 us +- 7 us/home/inada-n/work/python/fix-call-usage/python: ..................... 788 us +- 11 usMedian +- std dev: [/home/inada-n/work/python/cpython/python] 831 us +- 7 us -> [/home/inada-n/work/python/fix-call-usage/python] 788 us +- 11 us: 1.06x faster (-5%)# builtin min and max doesn't support FASTCALL$ ./python -m perf timeit --compare-to $HOME/work/python/cpython/python -s  'L = [0]*10000' -s 'import functools' -- 'functools.reduce(min, L)'/home/inada-n/work/python/cpython/python: ..................... 1.23 ms +- 0.00 ms/home/inada-n/work/python/fix-call-usage/python: ..................... 1.42 ms +- 0.04 msMedian +- std dev: [/home/inada-n/work/python/cpython/python] 1.23 ms +- 0.00 ms -> [/home/inada-n/work/python/fix-call-usage/python] 1.42 ms +- 0.04 ms: 1.16x slower (+16%)

@vstinnervstinner changed the titleFix some inefficient call API usagebpo-29548: Fix some inefficient call API usageFeb 15, 2017
Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Oh, I missed the "arg" variable.

@@ -2667,10 +2667,7 @@ FileHandler(ClientData clientData, int mask)
func = data->func;
file = data->file;

arg = Py_BuildValue("(Oi)", file, (long) mask);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

arg variable is no more used and can be removed, no?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thank you. I missed it.
Additionally, argument for "i" format should be int, not(long).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Additionally, argument for "i" format should be int, not (long).

Right, I spotted it as well, but then I forgot to report it, sorry :-) Hopefully you fixed it!

@vstinnervstinner added the performancePerformance or resource usage labelFeb 16, 2017
@methanemethane merged commit72dccde intopython:masterFeb 16, 2017
@methanemethane deleted the fix-call-usage branchFebruary 16, 2017 00:26
akruis pushed a commit to akruis/cpython that referenced this pull requestSep 9, 2017
This change removes the "static" declaration from the function slp_switch().This forces the compiler to adhere to the ABI specification.On i386 and amd64 it is now save to configure stackless with--enable-stacklessfewerregisters, except if you compile for darwin. The flagdisables explicit saving of %ebp/%rbp.On Unix-like systems the source file slp_transfer.c now gets compiledwith the additional flag -fno-inline-functions instead of -O2.https://bitbucket.org/stackless-dev/stackless/issues/98(grafted from 4f7698499ad53e5fad61fb415fbfe2c036672a9c)
akruis pushed a commit to akruis/cpython that referenced this pull requestSep 9, 2017
Mr3x33 added a commit to Mr3x33/cpython that referenced this pull requestSep 17, 2021
colesbury referenced this pull request in colesbury/nogilOct 6, 2021
This replaces the array of qbsr threads with a stack, whichallows us to get rid of the stop-the-world call. There wasan initialization order bug: registering a new qsbr threadmight stop-the-world, but stopping the world requires thethread to already be attached!This will probably make the qsbr scan even slower, but wecan improve that in the future.Fixes#97
ambv pushed a commit to ambv/cpython that referenced this pull requestApr 8, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@vstinnervstinnervstinner approved these changes

Assignees
No one assigned
Labels
performancePerformance or resource usage
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

4 participants
@methane@vstinner@zware@the-knights-who-say-ni

[8]ページ先頭

©2009-2025 Movatter.jp