Control.Lens是否有性能开销？

Question

我很欣赏Control.Lens包。它确实对Haskell记录语法稍弱的问题有所帮助。我正在开发一个库的一些部分，其中性能是一个令人担忧的问题。有没有人知道，与函数中的基本模式匹配相比，使用如下所示的类型类暴露的简单镜头的性能损失会是什么？使用这样的镜头有可能成为解决记录命名空间冲突问题的一种很好的方法。我可以自己设置一些基准，但我很好奇是否有人可以省去我的麻烦。谢谢。

镜头类

class LensX v where
  _x :: Functor f => (Double -> f Double) -> v -> f v

class LensY v where
  _y :: Functor f => (Double -> f Double) -> v -> f v

class LensZ v where
  _z :: Functor f => (Double -> f Double) -> v -> f v 

镜头实例

instance LensX Vec3 where
  _x f (Vec3 x y z) = fmap (\x' -> Vec3 x' y z) (f x)

instance LensY Vec3 where
  _y f (Vec3 x y z) = fmap (\y' -> Vec3 x y' z) (f y)

instance LensZ Vec3 where
  _z f (Vec3 x y z) = fmap (\z' -> Vec3 x y z') (f z)

提供镜头的模块不需要导入Control.Lens包，这很棒。这个库的用法在这个页面https://github.com/ekmett/lens/上有描述。

Answer 1

你为这种类型的镜头付出了很小的性能损失。它来自所有具有导致字典传递的约束的较高等级类型。

当您想要返回data-lens时，这是很少见的情况之一，它没有这个问题，甚至可以使您的代码更快。数据镜头，如果你解码Store联合间接，使用大约最直接的表示，你可以有一个镜头：

newtype Lens s a = Lens (s -> (a, a -> s))

虽然这个库本身不支持多态镜头，但你可以构建自己的镜头类型，它可以支持多态镜头，并且仍然可以提供高性能：

newtype Lens s t a b = Lens (s -> (a, b -> t))

对于您的特定用途，您可能还会对linear包感兴趣。