Export Data.Text.Lazy.Builder.Int.Integer

[phadej]

I was looking at https://hackage-content.haskell.org/package/text-2.1.4/docs/src/Data.Text.Lazy.Builder.Int.html#decimal and wondered how it can be efficient for Integers.

It's efficient because of rewrite rule to non-exported integer.

Is there a reason to not export integer for those who want to be explicit (and for whatever reason to not rely on RULES).

Similarly for boundedInteger

[phadej]

Looking more closely, integer has a base argument but only 10 and 16 are ones which probably work.

Maybe it's a better idea to have integer and hexadecimalInteger. I don't think that a bit of code duplication hard coding the base would hurt.

In fact, for base 16 the more efficient algorithm (essentially dumping the underlying bytes) would be better.

[Bodigrim]

Maybe it's a better idea to have integer and hexadecimalInteger.

I'm in favor of having explicit functions to convert Integer to either decimal or hexadecimal representations. I'd prefer more symmetry in names, like decimalInteger and hexadecimalInteger.

In fact, for base 16 the more efficient algorithm (essentially dumping the underlying bytes) would be better.

I suspect that people comparatively rarely want to print Integer in hexadecimal, which is normally only relevant for finite-bit types, so would not bother to spend time on optimizing and testing a new implementation.

@Lysxia what do you think?

[phadej]

not bother to spend time on optimizing and testing a new implementation.

In fact, toLazyText . fromString . show is faster then toLazyText . decimal. Especially for reasonably sized inputs. At extremely large Integer the gap narrows.

  show
    text
      proper
        64:    OK
          2.35 μs ±  87 ns
        128:   OK
          5.58 μs ± 421 ns
        256:   OK
          11.2 μs ± 1.1 μs
        512:   OK
          22.0 μs ± 1.4 μs
        1024:  OK
          45.9 μs ± 4.0 μs
        2048:  OK
          92.2 μs ± 8.8 μs
        4096:  OK
          196  μs ±  18 μs
        8192:  OK
          416  μs ±  25 μs
        16384: OK
          934  μs ±  70 μs
        32768: OK
          2.13 ms ± 212 μs
        65536: OK
          4.99 ms ± 435 μs
      base
        64:    OK
          976  ns ±  54 ns
        128:   OK
          2.08 μs ± 173 ns
        256:   OK
          4.17 μs ± 311 ns
        512:   OK
          8.37 μs ± 792 ns
        1024:  OK
          16.8 μs ± 778 ns
        2048:  OK
          36.3 μs ± 3.2 μs
        4096:  OK
          81.8 μs ± 6.3 μs
        8192:  OK
          192  μs ±  14 μs
        16384: OK
          465  μs ±  26 μs
        32768: OK
          1.17 ms ±  87 μs
        65536: OK
          3.08 ms ± 279 μs

so maybe it's worth some optimization. (The size is log10 of an input Integer).

[Bodigrim]

BTW how does text-builder-linear:fromUnboundedDec perform in your benchmark?

[phadej]

All
  show
    string
      base
        64:     OK
          790  ns ±  70 ns
        128:    OK
          1.74 μs ± 104 ns
        256:    OK
          3.67 μs ± 165 ns
        512:    OK
          7.35 μs ± 537 ns
        1024:   OK
          15.0 μs ± 1.5 μs
        2048:   OK
          32.9 μs ± 2.0 μs
        4096:   OK
          76.0 μs ± 5.9 μs
        8192:   OK
          180  μs ±  11 μs
        16384:  OK
          444  μs ±  22 μs
        32768:  OK
          1.12 ms ±  45 μs
        65536:  OK
          2.94 ms ± 190 μs
        131072: OK
          7.39 ms ± 347 μs
        262144: OK
          18.9 ms ± 876 μs
      proper
        64:     OK
          807  ns ±  68 ns
        128:    OK
          1.76 μs ± 172 ns
        256:    OK
          3.54 μs ± 164 ns
        512:    OK
          7.24 μs ± 702 ns
        1024:   OK
          15.1 μs ± 1.5 μs
        2048:   OK
          32.9 μs ± 2.8 μs
        4096:   OK
          75.8 μs ± 5.8 μs
        8192:   OK
          180  μs ± 3.5 μs
        16384:  OK
          442  μs ±  24 μs
        32768:  OK
          1.16 ms ± 102 μs
        65536:  OK
          2.93 ms ± 259 μs
        131072: OK
          7.36 ms ± 352 μs
        262144: OK
          18.8 ms ± 1.8 ms
    bs
      proper
        64:     OK
          742  ns ±  34 ns
        128:    OK
          1.43 μs ± 101 ns
        256:    OK
          2.34 μs ± 108 ns
        512:    OK
          4.33 μs ± 178 ns
        1024:   OK
          8.82 μs ± 831 ns
        2048:   OK
          19.7 μs ± 1.6 μs
        4096:   OK
          48.8 μs ± 3.2 μs
        8192:   OK
          126  μs ±  13 μs
        16384:  OK
          335  μs ±  25 μs
        32768:  OK
          899  μs ±  49 μs
        65536:  OK
          2.46 ms ± 201 μs
        131072: OK
          6.56 ms ± 370 μs
        262144: OK
          16.8 ms ± 1.0 ms
    text
      proper
        64:     OK
          2.53 μs ± 195 ns
        128:    OK
          5.90 μs ± 378 ns
        256:    OK
          11.6 μs ± 706 ns
        512:    OK
          23.7 μs ± 1.7 μs
        1024:   OK
          47.4 μs ± 3.4 μs
        2048:   OK
          97.2 μs ± 5.5 μs
        4096:   OK
          208  μs ±  12 μs
        8192:   OK
          438  μs ±  43 μs
        16384:  OK
          959  μs ±  47 μs
        32768:  OK
          2.13 ms ± 118 μs
        65536:  OK
          4.91 ms ± 381 μs
        131072: OK
          11.4 ms ± 893 μs
        262144: OK
          27.0 ms ± 2.3 ms
      base
        64:     OK
          984  ns ±  83 ns
        128:    OK
          2.07 μs ± 182 ns
        256:    OK
          4.18 μs ± 375 ns
        512:    OK
          8.46 μs ± 785 ns
        1024:   OK
          17.6 μs ± 1.5 μs
        2048:   OK
          37.7 μs ± 3.3 μs
        4096:   OK
          85.8 μs ± 5.5 μs
        8192:   OK
          198  μs ±  13 μs
        16384:  OK
          481  μs ±  44 μs
        32768:  OK
          1.20 ms ± 101 μs
        65536:  OK
          3.05 ms ± 168 μs
        131072: OK
          7.70 ms ± 750 μs
        262144: OK
          19.4 ms ± 1.5 ms
      linear
        64:     OK
          210  ns ±  14 ns
        128:    OK
          381  ns ±  23 ns
        256:    OK
          867  ns ±  50 ns
        512:    OK
          2.15 μs ± 207 ns
        1024:   OK
          6.35 μs ± 498 ns
        2048:   OK
          15.8 μs ± 1.5 μs
        4096:   OK
          41.2 μs ± 3.0 μs
        8192:   OK
          111  μs ± 6.8 μs
        16384:  OK
          305  μs ±  27 μs
        32768:  OK
          843  μs ±  19 μs
        65536:  OK
          2.36 ms ± 201 μs
        131072: OK
          6.34 ms ± 478 μs
        262144: OK
          16.8 ms ± 1.5 ms

Faster than going through show, but virtually the same as using bytestring integerDec , which is essentially the same algorithm as text uses now, i.e. a lot simpler (or at least shorter) than whatever text-builder-linear does. I think text-builder-linaer could be at least as fast as it is now, but simpler.