Skip to content
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

Decimal init performance #123

Merged
merged 3 commits into from
Nov 7, 2024
Merged

Decimal init performance #123

merged 3 commits into from
Nov 7, 2024

Conversation

mredig
Copy link
Contributor

@mredig mredig commented Nov 7, 2024

Well I figured out how signifcands and exponents work.... Or at least well enough to make the initializer much faster now.

I added a test to use the largest and smallest Decimal values as extreme cases and, while I don't know how long it took with the old method, it was longer than walking away and coming back to the computer. Now it's a fraction of a second.

I also made a quick safety fix to a buffer method since I caught it right after my last contribution.

guard integer.sign == .plus else { return nil }
assert(integer.floatingPointClass == .positiveNormal)

let significand = BigUInt("\(integer.significand)")!
Copy link
Collaborator

@tgymnich tgymnich Nov 7, 2024

Choose a reason for hiding this comment

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

There seems to be a public-ish field called _mantissa in Decimal which should be faster than using the string representation here. Maybe we should use this and keep the above arround maybe commented out just in case _mantissa goes away one day.

public var _mantissa: (UInt16, UInt16, UInt16, UInt16, UInt16, UInt16, UInt16, UInt16)

@@ -53,6 +53,7 @@ extension BigUInt {
let byteCount = (self.bitWidth + 7) / 8

let buffer = UnsafeMutableBufferPointer<UInt8>.allocate(capacity: byteCount)
buffer.initialize(repeating: 0)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Works, but setting the remaining bytes (0..<i) to zero after the loop below could be more efficient.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good thinking :)

@tgymnich
Copy link
Collaborator

tgymnich commented Nov 7, 2024

Awesome thank you. Left a few ideas for future improvements.

@tgymnich tgymnich merged commit 97a80fb into attaswift:master Nov 7, 2024
4 checks passed
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.

2 participants