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

Add Int64/UInt64 to Bigint slow conversion #204

Merged
merged 1 commit into from
Aug 14, 2022
Merged

Conversation

kateinoigakukun
Copy link
Member

@kateinoigakukun kateinoigakukun commented Aug 12, 2022

Int64 -> BigInt conversion can be done by passing two i32 without i64-bigint integration feature. This is a slow path, but useful for environments that have BigInt but don't have i64-bigint integration.

@github-actions
Copy link

github-actions bot commented Aug 12, 2022

Time Change: -276ms (1%)

Total Time: 19,142ms

Test name Duration Change
Serialization/Call JavaScript function directly 3ms +1ms 🚨
Serialization/Assign JavaScript number directly 3ms -1ms 🎉
Serialization/Call with JavaScript number directly 6ms +3ms (47%) 🚨
Serialization/Write JavaScript string directly 2ms -1ms (52%) 🏆
Serialization/Call with JavaScript string directly 4ms +2ms (44%) 🚨
Serialization/JavaScript function call through Wasm import 19ms +1ms (6%) 🔍
Serialization/JavaScript function call through Wasm import with int 17ms -3ms (19%) 👏
View Unchanged
Test name Duration Change
Serialization/JavaScript function call from Swift 567ms +7ms (1%)
Serialization/Swift Int to JavaScript with assignment 388ms -1ms
Serialization/Swift Int to JavaScript with call 2,120ms -44ms (2%)
Serialization/JavaScript Number to Swift Int 585ms -3ms (0%)
Serialization/Swift String to JavaScript with assignment 447ms -1ms
Serialization/Swift String to JavaScript with call 2,243ms -23ms (1%)
Serialization/JavaScript String to Swift String 5,388ms -151ms (2%)
Object heap/Increment and decrement RC 7,350ms -63ms (0%)

Copy link
Contributor

@MaxDesiatov MaxDesiatov left a comment

Choose a reason for hiding this comment

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

Overall LGTM. Do I understand correctly that the choice between the slow path and fast path is made explicitly by the user here?

@kateinoigakukun
Copy link
Member Author

Yes, the variant choice would be made in caller side for now.

@kateinoigakukun kateinoigakukun merged commit 9b865b2 into main Aug 14, 2022
@kateinoigakukun kateinoigakukun deleted the katei/bigint-int64 branch August 14, 2022 12:33
@kateinoigakukun
Copy link
Member Author

BTW, some of the benchmark cases are too fast and cause meaningless reports...

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