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

Add benchmarks for ctypes function call overhead#197

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

Open
mdboom wants to merge2 commits intopython:main
base:main
Choose a base branch
Loading
frommdboom:ctypes

Conversation

mdboom
Copy link
Contributor

This additionally adds support for building C extensions as part of creating a benchmark's virtual environment, since that didn't seem to be possible prior to this change.

Seefaster-cpython/ideas#370 for some background discussion.

@ericsnowcurrentlyericsnowcurrently self-requested a reviewMay 16, 2022 16:25
@mdboom
Copy link
ContributorAuthor

Wanted to add a note: This is definitely a "microbenchmark" that isn't a great example of a real-world workload.

Copy link
Member

@ericsnowcurrentlyericsnowcurrently left a comment

Choose a reason for hiding this comment

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

Mostly LGTM. There are some slight changes we should consider though, particularly usingrunner.bench_time_func() for micro benchmarks.

Comment on lines +29 to +75
void_foo_void()
int_foo_int(1)
void_foo_int(1)
void_foo_int_int(1, 2)
void_foo_int_int_int(1, 2, 3)
void_foo_int_int_int_int(1, 2, 3, 4)
void_foo_constchar(b"bytes")

Choose a reason for hiding this comment

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

The real benefit of micro-benchmarks is that it narrows down where performance regressions might be. With that in mind, would these different signatures have enough independent potential for regression that it would it make sense to have a separate benchmark for each? Would it be worth bothering even if they did?

Copy link
Member

@ericsnowcurrentlyericsnowcurrently left a comment

Choose a reason for hiding this comment

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

Thanks for the changes. I just have a couple more suggestions.

@kumaraditya303
Copy link
Contributor

LGTM, but I am a bit concerned that benchmarking all of the call argtypes in one iteration can hide regressions, but I can't think of anyway to fix that apart from splitting this benchmark further to each call argtypes.

Copy link
Member

@ericsnowcurrentlyericsnowcurrently left a comment

Choose a reason for hiding this comment

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

Mostly LGTM. I've left a few comments on a few minor things and to get clarification in a couple spots.

Copy link
Member

@ericsnowcurrentlyericsnowcurrently left a comment

Choose a reason for hiding this comment

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

A quick follow-up suggestion...

Copy link
Member

@ericsnowcurrentlyericsnowcurrently left a comment

Choose a reason for hiding this comment

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

LGTM

I'll leave it to you about my recommended change.

Copy link
Member

@ericsnowcurrentlyericsnowcurrently left a comment

Choose a reason for hiding this comment

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

LGTM

There's only one small suggestion, which I'll leave to your discretion.

if os.path.isfile(req):
name = os.path.basename(req)
if name == "setup.py":
req = os.path.dirname(req)

Choose a reason for hiding this comment

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

The reason we use the dirname isn't obvious, so it may be worth adding a comment here indicating pip's limitations.

Comment on lines +28 to +29
# pip doesn't support installing a setup.py,
# but it does support installing from the directory it is in.

Choose a reason for hiding this comment

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

This comment is what I was thinking of above. Consider moving it there.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@kumaraditya303kumaraditya303kumaraditya303 approved these changes

@ericsnowcurrentlyericsnowcurrentlyericsnowcurrently approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@mdboom@kumaraditya303@ericsnowcurrently

[8]ページ先頭

©2009-2025 Movatter.jp