这不是双向遍历吗？

Question

在haskell wiki的“编程技巧”部分，我找到了这个例子：

count :: (a -> Bool) -> [a] -> Int
count p = length . filter p

据说这是一个更好的选择

count :: (a -> Bool) -> [a] -> Int
count _ [] = 0
count p (x:xs)
   | p x       = 1 + count p xs
   | otherwise =     count p xs

就可读性而言，我完全同意。

但是，这不是双重遍历，因此实际上比显式递归函数更糟糕吗？ GHC中的惰性是否意味着这相当于优化后的单次遍历？哪种实现更快，为什么？

Answer 1

所以要看看优化器实际上做了什么，让我们look at the core：

% ghc -O2 -ddump-simpl Temp.hs
[1 of 1] Compiling Temp             ( Temp.hs, Temp.o )

==================== Tidy Core ====================
Result size of Tidy Core = {terms: 29, types: 26, coercions: 0}

Temp.count
  :: forall a_arN.
     (a_arN -> GHC.Types.Bool) -> [a_arN] -> GHC.Types.Int
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType <L,C(U)><S,1*U>,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True,
         ConLike=True, WorkFree=True, Expandable=True,
         Guidance=IF_ARGS [60 0] 191 0}]
Temp.count =
  \ (@ a_aMA)
    (p_arV :: a_aMA -> GHC.Types.Bool)
    (eta_B1 :: [a_aMA]) ->
    letrec {
      go_aNr [Occ=LoopBreaker]
        :: [a_aMA] -> GHC.Prim.Int# -> GHC.Types.Int
      [LclId, Arity=1, Str=DmdType <S,1*U>]
      go_aNr =
        \ (ds_aNs :: [a_aMA]) ->
          case ds_aNs of _ [Occ=Dead] {
            [] -> GHC.Types.I#;
            : y_aNx ys_aNy ->
              case p_arV y_aNx of _ [Occ=Dead] {
                GHC.Types.False -> go_aNr ys_aNy;
                GHC.Types.True ->
                  let {
                    g_a10B [Dmd=<L,C(U)>] :: GHC.Prim.Int# -> GHC.Types.Int
                    [LclId, Str=DmdType]
                    g_a10B = go_aNr ys_aNy } in
                  \ (x_a10C :: GHC.Prim.Int#) -> g_a10B (GHC.Prim.+# x_a10C 1)
              }
          }; } in
    go_aNr eta_B1 0

稍微清理一下：

Temp.count :: forall aType.  (aType -> Bool) -> [aType] -> Int
Temp.count = \(@ aType) (p :: aType -> Bool) (as :: [aType]) ->
  letrec {
    go :: [aType] -> GHC.Prim.Int# -> Int
    go = \(xs :: [aType]) ->
      case xs of _ {
        [] -> I#; -- constructor to make a GHC.Prim.Int# into an Int
        : y ys ->
          case p y of _ {
            False -> go ys;
            True ->
              let {
                go' :: GHC.Prim.Int# -> Int
                go' = go ys 
              } in \(x :: GHC.Prim.Int#) -> go' (GHC.Prim.+# x 1)
          }
      }; 
  } in go as 0

由于我们操作的是未装箱类型GHC.Prim.Int#、all the additions are strict，所以我们只有一个循环遍历数据。

Answer 2

无论哪种方式，您都必须对每个项目执行一到两个操作。必要的一项是检查谓词。第二个加 1 取决于谓词的结果。

所以，如果不考虑缓存等的影响，两种情况都会产生相同数量的操作。

我们得到的图是在第一种情况下有两个单独的遍历，一个收集元素，一个计算元素。给定一个大于缓存可以处理的列表，这将减慢处理速度。这实际上发生在 strict 语言中。

然而，Haskell 的懒惰在这里体现出来了。 filter 生成的列表被逐个元素地评估（存在），因为计数函数 length 需要它。然后由于length 仅将它们用于计数并且不保留对新创建列表的引用，因此这些元素可以立即免费被垃圾收集。所以在任何时候，计算过程中只占用O(1)内存。

在第一个版本中构建结果“过滤”列表有一点开销。但与列表很大时出现的缓存效应相比，这通常可以忽略不计。 （对于小型列表，这可能很重要；这需要进行测试。）此外，它可能会根据编译器和选择的优化级别进行优化。

更新。第二个版本实际上会消耗内存，正如其中一个 cmets 所指出的那样。为了公平比较，您需要在正确的位置使用累积参数和严格性注释器编写它，因为（我希望）length 已经这样编写了。

Answer 3

您可以使用profiling 测试哪个版本更快，例如：

module Main where


main :: IO ()
main = print countme'

count' :: (a -> Bool) -> [a] -> Int
count' p = length . filter p

count :: (a -> Bool) -> [a] -> Int
count _ [] = 0
count p (x:xs)
   | p x       = 1 + count p xs
   | otherwise =     count p xs


list = [0..93823249]

countme' = count' (\x -> x `mod` 15 == 0) list
countme = count (\x -> x `mod` 15 == 0) list

然后运行ghc -O2 -prof -fprof-auto -rtsopts Main.hs 和./Main +RTS -p。它将产生文件 Main.prof。然后将主函数更改为使用countme 并比较结果。我的是：

• 4.12s 用于隐式版本
• 6.34s 用于显式版本

如果您关闭优化，那么隐式优化仍然会稍微（但不多）快。

除了前面已经解释过的融合和惰性之外，我想还有一个原因可能是length和filter是Prelude函数，可以更好地被编译器优化。