Skip to content

[swiftSyntax] Performance improvements for deserialising ByteTrees #18888

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
merged 7 commits into from
Aug 29, 2018

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented Aug 22, 2018

This PR contains several performance for deserialising syntax trees in binary encoding (see the separate commits):

  • Make SourceLength a struct
    • It should have been one all the while
  • Make RawSyntaxData a direct enum
    • I do not see any reason why it shouldn't be
  • Make ByteTree(Object)Reader a struct and pass a reference to it around using an UnsafeMutabelPointer
    • This improves the deserialisation performance by 13% because we are able to eliminate unnecessary retain and release calls
  • Only reference userInfo through an UnsafePointer and don't pass it around
    • This improves deserialisation performance by another 11% because we are again able to eliminate unnecessary retain/release calls
  • Use the more efficient array initialiser that was introduced in Add an array initializer with access to uninitialized storage #17774

@ahoppen ahoppen requested review from rintaro and nkcsgexi August 22, 2018 03:53
@ahoppen
Copy link
Member Author

ahoppen commented Aug 22, 2018

@swift-ci Please smoke test

@@ -48,32 +48,34 @@ protocol ByteTreeObjectDecodable {
/// - numFields: The number of fields that are present in the serialized
/// object
/// - Returns: The deserialized object
static func read(from reader: ByteTreeObjectReader, numFields: Int,
userInfo: [ByteTreeUserInfoKey: Any]) -> Self
static func read(from reader: UnsafeMutablePointer<ByteTreeObjectReader>,
Copy link
Member

Choose a reason for hiding this comment

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

So why not inout ByteTreeObjectReader?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because inout ByteTreeObjectReader still has a retain/release count associated with it.

@ahoppen ahoppen force-pushed the swiftsyntax-performance-improvments branch from 6f3c306 to 31db50e Compare August 27, 2018 21:47
@ahoppen ahoppen force-pushed the swiftsyntax-performance-improvments branch from 31db50e to a7942e1 Compare August 27, 2018 22:19
@ahoppen
Copy link
Member Author

ahoppen commented Aug 27, 2018

@swift-ci Please smoke test and merge

@ahoppen
Copy link
Member Author

ahoppen commented Aug 28, 2018

Bots were unable to clone the projects. Let's try again.

@swift-ci Please smoke test and merge

@ahoppen
Copy link
Member Author

ahoppen commented Aug 28, 2018

Let's see if swift-ci is working again.

@swift-ci Please smoke test and merge

@ahoppen
Copy link
Member Author

ahoppen commented Aug 28, 2018

@swift-ci Please smoke test

@ahoppen ahoppen force-pushed the swiftsyntax-performance-improvments branch from a7942e1 to d41af61 Compare August 29, 2018 00:45
@ahoppen
Copy link
Member Author

ahoppen commented Aug 29, 2018

@swift-ci Please smoke test

@ahoppen ahoppen merged commit f50ddf9 into swiftlang:master Aug 29, 2018
@ahoppen ahoppen deleted the swiftsyntax-performance-improvments branch August 29, 2018 15:56
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