Open oscbyspro opened 1 year ago
Adding the top-secret™ _lowWord
accessor makes the StdlibRadix10
case 30% faster.
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).
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.
I’ve not kept track of what changes are responsible, but:
10
stdlib encoding is down to 3.750
from 4.783
seconds16
stdlib encoding is down to 7.790
from 12.986
secondsAdding custom smart-shifts reduces base 16
stdlib encoding to 4.284
seconds.
I'm pretty sure (#88) sent the base 10 case to an outer ring of Tuple's Inferno™
10
stdlib encoding is up
to 5.007
from 3.750
seconds.16
stdlib encoding is down
to 4.038
from 4.284
seconds.
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 :tm: 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 inString.init(some BinaryInteger, radix: Int, uppercase: Bool)
: