Skip to content

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.

See faster-cpython/ideas#370 for some background discussion.

@ericsnowcurrentlyericsnowcurrently self-requested a review May 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 using runner.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.

@kumaraditya303kumaraditya303 self-requested a review June 7, 2022 17:00
@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.

ifos.path.isfile(req):
name=os.path.basename(req)
ifname=="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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@mdboom@kumaraditya303@ericsnowcurrently