[GHC] #9638: Speed up Data.Char.isDigit

[GHC]

#9638: Speed up Data.Char.isDigit
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:
                  Type:  feature     |           Status:  new
  request                            |        Milestone:  7.10.1
              Priority:  normal      |          Version:  7.9
             Component:              |         Keywords:
  libraries/base                     |     Architecture:  Unknown/Multiple
            Resolution:              |       Difficulty:  Easy (less than 1
      Operating System:              |  hour)
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 Replying to [comment:3 carter]:
 > These sound reasonable, do we have any (micro)benchmarks to validate
 that there's a meaningful improvement in performance to pay down the
 increased complexity of the implementation?

 Yes. I tested evaluating `nf (map isDigit) testcase` with the following
 test cases:

 {{{#!hs
 toosmall = replicate 700 '-'
 toobig = replicate 700 'a'
 justright = replicate 700 '7'
 arb =
 "12asaa489oneuhl98'c43rub93d'i'i98car278urnatehodth98228hteou84348hcae84---
 - -   424  42 hteohu 2   4hto24hth    ehua942dp.dghckbaa---;    48923"
 arbitrary = arb ++ arb ++ reverse arb ++ reverse arb
 }}}

 As expected, the fancy code seemed to be very slightly worse for
 `toosmall`, certainly not worse enough to really get a proper measurement
 (it's only one extra addition). The rest did better with the fancy code;
 the difference was consistently biggest for `arbitrary`. Obviously we're
 not talking huge changes, but I think this function and similar ones get a
 good bit of use, so it's probably worth bothering.

 {{{
 benchmarking toosmall/old
 time                 12.31 μs   (12.27 μs .. 12.36 μs)
                      1.000 R²   (0.999 R² .. 1.000 R²)
 mean                 12.37 μs   (12.34 μs .. 12.40 μs)
 std dev              100.2 ns   (69.41 ns .. 138.7 ns)

 benchmarking toosmall/new
 time                 12.42 μs   (12.41 μs .. 12.43 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 12.43 μs   (12.42 μs .. 12.44 μs)
 std dev              36.07 ns   (24.75 ns .. 59.63 ns)

 benchmarking toobig/old
 time                 13.05 μs   (13.04 μs .. 13.06 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 13.05 μs   (13.04 μs .. 13.06 μs)
 std dev              26.99 ns   (19.95 ns .. 43.44 ns)

 benchmarking toobig/new
 time                 12.43 μs   (12.42 μs .. 12.45 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 12.45 μs   (12.44 μs .. 12.48 μs)
 std dev              65.84 ns   (32.99 ns .. 129.0 ns)

 benchmarking justright/old
 time                 13.07 μs   (13.06 μs .. 13.08 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 13.08 μs   (13.06 μs .. 13.09 μs)
 std dev              42.63 ns   (30.33 ns .. 56.90 ns)

 benchmarking justright/new
 time                 12.41 μs   (12.40 μs .. 12.42 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 12.41 μs   (12.41 μs .. 12.42 μs)
 std dev              25.29 ns   (21.00 ns .. 31.20 ns)

 benchmarking arbitrary/old
 time                 11.69 μs   (11.68 μs .. 11.71 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 11.69 μs   (11.68 μs .. 11.71 μs)
 std dev              50.41 ns   (21.45 ns .. 85.71 ns)

 benchmarking arbitrary/new
 time                 10.65 μs   (10.64 μs .. 10.66 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 10.65 μs   (10.64 μs .. 10.66 μs)
 std dev              21.31 ns   (14.90 ns .. 36.62 ns)
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9638#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler