The following higher order function, sumh, seems to be 3 to 14 times slower than the equivalent recursive function, sumr:

sumh :: Double -> Double                     
sumh n =
    snd $ until ((>= n) . fst) as' (1, 0)
    where
      as' (i,s) =
          (i + 2, s + (-1) / i + 1 / (i + 1))

sumr :: Double -> Double
sumr n =
    as' 1 0
    where
      as' i  s
          | i >= n    = s
          | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))

This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From the size usage my guess is that this is due to the allocation of tuples in sumh. Maybe there is a straightforward way to optimize sumh but I couldn't find it. Adding a Strict pragma didn't help nor did use of -funbox-strict-fields -flate-dmd-anal. Have I missed something or should I file a bug? 

Timings from 8.0.1 rc2:

ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
bash-3.2$ ghc -O2 -dynamic sum.hs
ghc -O2 -dynamic sum.hs
[1 of 1] Compiling Main             ( sum.hs, sum.o )
Linking sum ...
bash-3.2$ ghci
Prelude> :load sum
Ok, modules loaded: Main.
(0.05 secs,)
Prelude Main> sumh (10^6)
-0.6931466805602525
it :: Double
(0.14 secs, 40,708,016 bytes)
Prelude Main> sumr (10^6)
-0.6931466805602525
it :: Double
(0.01 secs, 92,000 bytes)

Thanks
George