Skip to content

[AST] Perf: Improve getDesugaredType() efficiency #13691

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

davezarzycki
Copy link
Contributor

Make getDesugaredType() as fast as possible for now. With the old way:

  1. Switching over the sugared types turned into a frequently mispredicted branch because the sugar in the type system is random as far as the processor is concerned.
  2. Storing the underlying/singlely-desugared type at different offsets in memory adds more code bloat and misprediction.

Short of a major redesign to avoid pointer chasing, this is probably as fast as the method will get.

@DougGregor / @CodaFi / @slavapestov – With this change, NameAliasType now caches some – but not all – results to avoid pointer chasing (just like the syntax sugared types do so they don't need to ask the AST ever time). My question is this, is the caching I setup in getSinglyDesugaredTypeSlow() correct? Could it cache more? It certainly cannot cache all results, otherwise a couple tests break.

Make getDesugaredType() as fast as possible for now. With the old way:

1) Switching over the sugared types turned into a frequently
   mispredicted branch because the sugar in the type system is random
   as far as the processor is concerned.
2) Storing the underlying/singlely-desugared type at different offsets
   in memory adds more code bloat and misprediction.

Short of a major redesign to avoid pointer chasing, this is probably as
fast as the method will get.
@davezarzycki
Copy link
Contributor Author

@swift-ci please test

@davezarzycki
Copy link
Contributor Author

davezarzycki commented Jan 3, 2018

For reference, if we cache all NameAliasType desugaring, then compiler_crashers_2_fixed/0114-rdar33189068.swift crashes because an instance of NameAliasType changes its underlying type from one GenericTypeParam to another.

@jckarter
Copy link
Contributor

jckarter commented Jan 3, 2018

What sort of performance impact does this have in practice?

@slavapestov
Copy link
Contributor

The underlying type of a TypeAliasDecl should never change after being computed. We should add an assertion somewhere for that.

@davezarzycki
Copy link
Contributor Author

Hi @slavapestov – If we add an assert, then compiler_crashers_2_fixed/0114-rdar33189068.swift will crash. Want a bug report for now?

@davezarzycki
Copy link
Contributor Author

Hi Joe – On my "Kaby Lake" MacBook Pro, I see about a 3.57% improvement when building Swift.swiftmodule

@davezarzycki davezarzycki merged commit 1ebc8e9 into swiftlang:master Jan 3, 2018
@davezarzycki davezarzycki deleted the nfc_perf_getDesugaredType2 branch January 3, 2018 22:20
@davezarzycki
Copy link
Contributor Author

Hi @slavapestov – Just FYI: https://bugs.swift.org/browse/SR-6694

@jckarter
Copy link
Contributor

jckarter commented Jan 3, 2018

@davezarzycki Nice!

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