KEMBAR78
[mypyc] Inline increfs and decrefs in commonly executed blocks by JukkaL · Pull Request #11540 · python/mypy · GitHub
Skip to content

Conversation

JukkaL
Copy link
Collaborator

@JukkaL JukkaL commented Nov 13, 2021

These operations are performance-critical, but inlining everywhere
can slow down compilation a lot, so we only inline them outside error
handlers (and other rarely executed code paths).

This still can slow compilation by 10-15%, but I think that we just need
to live with it, since the performance gains are impressive. We can perhaps
claw back some of the loss by optimizing away redundant increfs/decrefs.
Also parallel compilation would make this much less significant.

This can speed up the richards benchmark by 65% (!).

With this change:

running richards
...........
interpreted: 0.181880s (avg of 6 iterations; stdev 0.91%)
compiled:    0.005314s (avg of 6 iterations; stdev 1.2%)

compiled is 34.229x faster

Using master:

running richards
...........
interpreted: 0.182124s (avg of 6 iterations; stdev 2.1%)
compiled:    0.008794s (avg of 6 iterations; stdev 1.9%)

compiled is 20.710x faster

Also, this makes the int_list microbenchmark up to 80% faster.
Compiled mypy was also around 3% faster.

These operations are performance-critical, but inlining everywhere
can slow down compilation a lot, so we only inline them outside error
handlers (and other rarely executed code paths).

This still can slow compilation by 10-15%, but I think that we just need
to live with it, since the performance gains are impressive. We can perhaps
claw back some of the loss by optimizing away redundant increfs/decrefs.
Also parallel compilation would make this much less significant.

This can speed up the richards benchmark by 65% (!).

With this change:

```
running richards
...........
interpreted: 0.181880s (avg of 6 iterations; stdev 0.91%)
compiled:    0.005314s (avg of 6 iterations; stdev 1.2%)

compiled is 34.229x faster
```

Using master:

```
running richards
...........
interpreted: 0.182124s (avg of 6 iterations; stdev 2.1%)
compiled:    0.008794s (avg of 6 iterations; stdev 1.9%)

compiled is 20.710x faster
```

Also, this makes the int_list microbenchmark up to 80% faster.
Compiled mypy was also around 3% faster.
@JukkaL
Copy link
Collaborator Author

JukkaL commented Nov 13, 2021

Partially related to #11547.

Copy link
Collaborator

@msullivan msullivan left a comment

Choose a reason for hiding this comment

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

This looks good. Great idea.

Copy link
Collaborator

@97littleleaf11 97littleleaf11 left a comment

Choose a reason for hiding this comment

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

lgtm!

@97littleleaf11 97littleleaf11 merged commit 7a5c6f0 into master Nov 15, 2021
@97littleleaf11 97littleleaf11 deleted the inline-refcount branch November 15, 2021 08:33
tushar-deepsource pushed a commit to DeepSourceCorp/mypy that referenced this pull request Jan 20, 2022
…n#11540)

These operations are performance-critical, but inlining everywhere
can slow down compilation a lot, so we only inline them outside error
handlers (and other rarely executed code paths).

This still can slow compilation by 10-15%, but I think that we just need
to live with it, since the performance gains are impressive. We can perhaps
claw back some of the loss by optimizing away redundant increfs/decrefs.
Also parallel compilation would make this much less significant.

This can speed up the richards benchmark by 65% (!).

With this change:

```
running richards
...........
interpreted: 0.181880s (avg of 6 iterations; stdev 0.91%)
compiled:    0.005314s (avg of 6 iterations; stdev 1.2%)

compiled is 34.229x faster
```

Using master:

```
running richards
...........
interpreted: 0.182124s (avg of 6 iterations; stdev 2.1%)
compiled:    0.008794s (avg of 6 iterations; stdev 1.9%)

compiled is 20.710x faster
```

Also, this makes the int_list microbenchmark up to 80% faster.
Compiled mypy was also around 3% faster.
Sign up for free to 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