#长度 #解码 #运行 #编码 #类型 #最快 #数据

已删除 rle-decode-helper

在Rust中实现任何类型编码数据的解码最快方式。编写一个既快又安全的解码器可能相当具有挑战性,因此这个crate旨在让您免于维护和测试自己的实现带来的麻烦。

1.0.0-alpha2 2019年6月26日

#19 in #最快

MIT/Apache

41KB
99

rle-decode-helper

在Rust中实现任何类型编码数据的解码最快方式。

编写一个既快又安全的解码器可能相当具有挑战性,因此这个crate旨在让您免于维护和测试自己的实现带来的麻烦。

使用方法

当然,您需要依赖这个crate

rle-decode-helper = "1.0.0-alpha"

只有一个函数可以使用,rle_decode<T>(&mut Vec<T>, lookbehind_size: usize, fill_length: usize)。它需要

  • 一个要修改的向量,
  • 从该向量复制的项目数(基本上 vector[(vector.len() - lookbehind)..])
  • 要追加的项目数。之后,向量将包含额外的 fill_length 项。
use rle_decode_helper::rle_decode;

let mut decode_buffer = vec![0, 0, 1, 1, 0, 2, 3];
let lookbehind_length = 4;
let output_length = 10;
rle_decode(&mut decode_buffer, lookbehind_length, output_length);
assert_eq!(decode_buffer, [0, 0, 1, 1, 0, 2, 3, 1, 0, 2, 3, 1, 0, 2, 3, 1, 0]);

恐慌

在某些情况下,解码函数会引发恐慌

  • lookbehind长度为0
  • lookbehind长度大于Vec的长度
  • 输出长度 + Vec的长度会溢出

背景

这个crate的初衷源于 这篇预RFC。它引起了对标准库的一个弱点关注,导致一些crate编写了自己的不安全绕过。

在预RFC的探索过程中,进行了一些实验。例如,请参见 这里这里

一些统计数据

这里有一个基准测试,比较了朴素(重复推送)实现、可能导致未初始化内存的脆弱实现和这个crate。

对于非常小的回溯长度为2的测试结果 lookbehind=2 以及对于更大的回溯长度为333的测试结果 lookbehind=333

许可证

许可协议为以下之一

任选其一。

贡献

除非您明确说明,否则任何有意提交以包含在作品中的贡献,如Apache-2.0许可证中定义,应按上述方式双重许可,不附加任何额外条款或条件。

无运行时依赖