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

Stdlib encoding performance #60

Open
oscbyspro opened this issue Mar 8, 2023 · 6 comments
Open

Stdlib encoding performance #60

oscbyspro opened this issue Mar 8, 2023 · 6 comments
Labels
brrr such code, much wow help please send help :(

Comments

@oscbyspro
Copy link
Owner

oscbyspro commented Mar 8, 2023

Given that the package provides alternative coding methods via the ANKBigEndianTextCodable protocol, the following is more vexing than problematic. Having said that, if somebody wants to take a deep dive into Protocol Witness Hell ™️ and figure out how to make the stdlib encoding method perform - that'd be cool. As you can see in the list below, there's some funky business going on in String.init(some BinaryInteger, radix: Int, uppercase: Bool):

Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testDecodingRadix10]' passed (0.017 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testDecodingRadix16]' passed (0.016 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testEncodingRadix10]' passed (0.015 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testEncodingRadix16]' passed (0.005 seconds).

Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testDecodingUsingSwiftStdlibRadix10]' passed (0.037 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testDecodingUsingSwiftStdlibRadix16]' passed (0.034 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testEncodingUsingSwiftStdlibRadix10]' passed (5.007 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testEncodingUsingSwiftStdlibRadix16]' passed (4.038 seconds).
@oscbyspro oscbyspro added brrr such code, much wow help please send help :( labels Mar 8, 2023
@oscbyspro
Copy link
Owner Author

oscbyspro commented Mar 11, 2023

Adding the top-secret™ _lowWord accessor makes the StdlibRadix10 case 30% faster.

oscbyspro added a commit that referenced this issue Mar 11, 2023
@oscbyspro
Copy link
Owner Author

oscbyspro commented Apr 6, 2023

Just look at that 2600x base 16 encoding ratio...

Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testEncodingRadix16]' passed (0.005 seconds).
Test Case '-[ANKFullWidthKitBenchmarks.UInt256BenchmarksOnText testEncodingUsingSwiftStdlibRadix16]' passed (12.986 seconds).

@oscbyspro
Copy link
Owner Author

oscbyspro commented Apr 8, 2023

The base 10 case is ironically made 2x faster by omitting the fast paths in the binary integer init methods. Well, I won’t do that as it should only matter when they are unspecialized, which for my purposes means never. Using a more efficient form of type testing (#71) might have a similar effect, however.

@oscbyspro
Copy link
Owner Author

oscbyspro commented Apr 16, 2023

I’ve not kept track of what changes are responsible, but:

  • base 10 stdlib encoding is down to 3.750 from 4.783 seconds
  • base 16 stdlib encoding is down to 7.790 from 12.986 seconds

@oscbyspro
Copy link
Owner Author

oscbyspro commented Apr 17, 2023

Adding custom smart-shifts reduces base 16 stdlib encoding to 4.284 seconds.

oscbyspro added a commit that referenced this issue Apr 18, 2023
@oscbyspro
Copy link
Owner Author

oscbyspro commented Apr 21, 2023

I'm pretty sure (#88) sent the base 10 case to an outer ring of Tuple's Inferno™

  • base 10 stdlib encoding is up to 5.007 from 3.750 seconds.
  • base 16 stdlib encoding is down to 4.038 from 4.284 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brrr such code, much wow help please send help :(
Projects
None yet
Development

No branches or pull requests

1 participant