gpt4 book ai didi

haskell - 有效地创建严格的 ByteStrings

转载 作者:行者123 更新时间:2023-12-04 01:03:47 24 4
gpt4 key购买 nike

最近在我的项目上运行基准测试后,我发现直接构建严格的字节串可以比涉及构建器的构建快一个数量级。

例如,使用构建器的编码器实现:

encoder :: Int64 -> Data.ByteString.ByteString
encoder =
Data.ByteString.Lazy.toStrict .
Data.ByteString.Builder.toLazyByteString .
Data.ByteString.Builder.int64BE

性能比直接构造字节串的方法差 10 倍,并且有多种进一步优化的可能性:
encoder :: Int64 -> Data.ByteString.ByteString
encoder =
unpackIntBySize 8

unpackIntBySize :: (Bits a, Integral a) => Int -> a -> Data.ByteString.ByteString
unpackIntBySize n x =
Data.ByteString.pack $ map f $ reverse [0..n - 1]
where
f s =
fromIntegral $ shiftR x (8 * s)

所以我的问题有两个:
  • 为什么Builder没有直接转换严格ByteString ?很烦,因为我经常要导入Data.ByteString.Lazy只是为了使用它的toStrict函数,因为 Data.ByteString.Builder仅公开 toLazyByteString .
  • 然而,所提到的经历让我想知道,如果它不存在是有原因的。原因是我完全应用了不正确的使用模式。那么,这确实是不正确的,是否有更好的选择?顺便说一句,我知道 Data.ByteString.Builder.Prim ,但我怀疑在上述情况下使用它会产生很大的不同。
  • 最佳答案

    Builder 不是零成本的抽象,它针对大型惰性字符串进行了优化。来自建筑商docs :

    The current implementation is tuned for an average chunk size between 4kb and 32kb



    在您的情况下,构建器分配整个 4k block 只是为了产生 8 个字节。

    pack 进行比较,它计算必要的缓冲区大小,分配它,然后在循环中填充它。效率低下的唯一来源是 8 个列表 Word8预先分配。大概 unfoldrN 会更有效率。

    使用 builder 构造小的严格字节串有时很方便,但有更好的方法。

    关于haskell - 有效地创建严格的 ByteStrings,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33195628/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com