“功能性” Rust对性能有何影响？

Question

我正在跟踪Exercism.io上的Rust曲目。我有大量的C / C ++经验。我喜欢Rust的“功能性”元素，但我担心相对性能。

我解决了'run length encoding' problem：

pub fn encode(source: &str) -> String {
    let mut retval = String::new();
    let firstchar = source.chars().next();
    let mut currentchar = match firstchar {
        Some(x) => x,
        None => return retval,
    };
    let mut currentcharcount: u32 = 0;
    for c in source.chars() {
        if c == currentchar {
            currentcharcount += 1;
        } else {
            if currentcharcount > 1 {
                retval.push_str(&currentcharcount.to_string());
            }
            retval.push(currentchar);
            currentchar = c;
            currentcharcount = 1;
        }
    }
    if currentcharcount > 1 {
        retval.push_str(&currentcharcount.to_string());
    }
    retval.push(currentchar);
    retval
}

我注意到，评分最高的答案之一看起来更像这样：

extern crate itertools;

use itertools::Itertools;

pub fn encode(data: &str) -> String {
    data.chars()
        .group_by(|&c| c)
        .into_iter()
        .map(|(c, group)| match group.count() {
            1 => c.to_string(),
            n => format!("{}{}", n, c),
        })
        .collect()
}

我喜欢最受好评的解决方案；它简单，实用且优雅。这就是他们向我保证Rust将会实现的一切。另一方面，我的是总的，充满了可变的变量。你可以说我已经习惯了C ++。

我的问题是功能样式会对性能产生重大影响。我使用相同的4MB随机数据进行了1000次编码，测试了这两个版本。我的命令性解决方案花了不到10秒的时间；功能解决方案约为2分钟30秒。

• 为什么功能样式比命令式样式慢得多？
• 功能实现是否存在一些问题，从而导致如此大的减速？
• 如果我想编写高性能代码，我是否应该永远使用这种功能样式？

Answer 1

TL; DR

在某些情况下，功能实现 可能比原始过程实现更快。

  

为什么功能样式比命令式样式慢得多？功能实现是否存在一些问题，从而导致如此大的速度下降？

与Matthieu M. already pointed out一样，要注意的重要事项是算法很重要。该算法的表达方式（过程性，命令性，面向对象，功能性，声明性）通常无关紧要。

我看到功能代码有两个主要问题：

• 一遍又一遍地分配多个字符串效率很低。在原始功能实现中，这是通过to_string和format!完成的。

• 使用group_by会产生开销，而存在pub fn encode_slim(data: &str) -> String { data.chars() .batching(|it| { it.next() .map(|v| (v, it.take_while_ref(|&v2| v2 == v).count() + 1)) }) .format_with("", |(c, count), f| match count { 1 => f(&c), n => f(&format_args!("{}{}", n, c)), }) .to_string() } 来产生嵌套的 iterator ，而您并不需要获取计数。

使用itertools（batching，take_while_ref，format_with）的更多可以使这两种实现更加接近：

RUSTFLAGS='-C target-cpu=native'

使用encode (procedural) time: [21.082 ms 21.620 ms 22.211 ms] encode (fast) time: [26.457 ms 27.104 ms 27.882 ms] Found 7 outliers among 100 measurements (7.00%) 4 (4.00%) high mild 3 (3.00%) high severe 编译的4MiB随机字母数字数据基准：

struct RunLength<I> {
    iter: I,
    saved: Option<char>,
}

impl<I> RunLength<I>
where
    I: Iterator<Item = char>,
{
    fn new(mut iter: I) -> Self {
        let saved = iter.next(); // See footnote 1
        Self { iter, saved }
    }
}

impl<I> Iterator for RunLength<I>
where
    I: Iterator<Item = char>,
{
    type Item = (char, usize);

    fn next(&mut self) -> Option<Self::Item> {
        let c = self.saved.take().or_else(|| self.iter.next())?;

        let mut count = 1;
        while let Some(n) = self.iter.next() {
            if n == c {
                count += 1
            } else {
                self.saved = Some(n);
                break;
            }
        }

        Some((c, count))
    }
}

pub fn encode_tiny(data: &str) -> String {
    use std::fmt::Write;

    RunLength::new(data.chars()).fold(String::new(), |mut s, (c, count)| {
        match count {
            1 => s.push(c),
            n => write!(&mut s, "{}{}", n, c).unwrap(),
        }
        s
    })
}

如果您对创建自己的迭代器感兴趣，可以将过程代码与更多功能代码混合搭配：

RUSTFLAGS='-C target-cpu=native'

1 —感谢Stargateur for pointing out急于获得第一个值有助于分支预测。

使用encode (procedural) time: [19.888 ms 20.301 ms 20.794 ms] Found 4 outliers among 100 measurements (4.00%) 3 (3.00%) high mild 1 (1.00%) high severe encode (tiny) time: [19.150 ms 19.262 ms 19.399 ms] Found 11 outliers among 100 measurements (11.00%) 5 (5.00%) high mild 6 (6.00%) high severe 编译的4MiB随机字母数字数据基准：

next

我相信，这更清楚地显示了这两种实现之间的主要基本区别：基于迭代器的解决方案是 resumable 。每次调用self.saved时，都需要查看是否有一个先前读取的字符（String）。这会为程序代码中不存在的代码添加一个分支。

在另一方面，基于迭代器的解决方案更加灵活-我们现在可以对数据进行各种转换，或者直接写入文件而不是char，等等。自定义迭代器可以也可以扩展为在通用类型上运行，而不是在use criterion::{criterion_group, criterion_main, Criterion}; // 0.2.11 use rle::*; fn criterion_benchmark(c: &mut Criterion) { let data = rand_data(4 * 1024 * 1024); c.bench_function("encode (procedural)", { let data = data.clone(); move |b| b.iter(|| encode_proc(&data)) }); c.bench_function("encode (functional)", { let data = data.clone(); move |b| b.iter(|| encode_iter(&data)) }); c.bench_function("encode (fast)", { let data = data.clone(); move |b| b.iter(|| encode_slim(&data)) }); c.bench_function("encode (tiny)", { let data = data.clone(); move |b| b.iter(|| encode_tiny(&data)) }); } criterion_group!(benches, criterion_benchmark); criterion_main!(benches); 上运行，从而使其非常灵活。

另请参阅：

• How can I add new methods to Iterator?

  

如果我想编写高性能代码，是否应该使用这种功能样式？

我会的，直到基准测试表明这是瓶颈。然后评估为什么是瓶颈。

支持代码

总是要展示你的作品，对吧？

benchmark.rs

use itertools::Itertools; // 0.8.0
use rand; // 0.6.5

pub fn rand_data(len: usize) -> String {
    use rand::distributions::{Alphanumeric, Distribution};
    let mut rng = rand::thread_rng();
    Alphanumeric.sample_iter(&mut rng).take(len).collect()
}

pub fn encode_proc(source: &str) -> String {
    let mut retval = String::new();
    let firstchar = source.chars().next();
    let mut currentchar = match firstchar {
        Some(x) => x,
        None => return retval,
    };
    let mut currentcharcount: u32 = 0;
    for c in source.chars() {
        if c == currentchar {
            currentcharcount += 1;
        } else {
            if currentcharcount > 1 {
                retval.push_str(&currentcharcount.to_string());
            }
            retval.push(currentchar);
            currentchar = c;
            currentcharcount = 1;
        }
    }
    if currentcharcount > 1 {
        retval.push_str(&currentcharcount.to_string());
    }
    retval.push(currentchar);
    retval
}

pub fn encode_iter(data: &str) -> String {
    data.chars()
        .group_by(|&c| c)
        .into_iter()
        .map(|(c, group)| match group.count() {
            1 => c.to_string(),
            n => format!("{}{}", n, c),
        })
        .collect()
}

pub fn encode_slim(data: &str) -> String {
    data.chars()
        .batching(|it| {
            it.next()
                .map(|v| (v, it.take_while_ref(|&v2| v2 == v).count() + 1))
        })
        .format_with("", |(c, count), f| match count {
            1 => f(&c),
            n => f(&format_args!("{}{}", n, c)),
        })
        .to_string()
}

struct RunLength<I> {
    iter: I,
    saved: Option<char>,
}

impl<I> RunLength<I>
where
    I: Iterator<Item = char>,
{
    fn new(mut iter: I) -> Self {
        let saved = iter.next();
        Self { iter, saved }
    }
}

impl<I> Iterator for RunLength<I>
where
    I: Iterator<Item = char>,
{
    type Item = (char, usize);

    fn next(&mut self) -> Option<Self::Item> {
        let c = self.saved.take().or_else(|| self.iter.next())?;

        let mut count = 1;
        while let Some(n) = self.iter.next() {
            if n == c {
                count += 1
            } else {
                self.saved = Some(n);
                break;
            }
        }

        Some((c, count))
    }
}

pub fn encode_tiny(data: &str) -> String {
    use std::fmt::Write;

    RunLength::new(data.chars()).fold(String::new(), |mut s, (c, count)| {
        match count {
            1 => s.push(c),
            n => write!(&mut s, "{}{}", n, c).unwrap(),
        }
        s
    })
}

#[cfg(test)]
mod test {
    use super::*;

    #[test]
    fn all_the_same() {
        let data = rand_data(1024);

        let a = encode_proc(&data);
        let b = encode_iter(&data);
        let c = encode_slim(&data);
        let d = encode_tiny(&data);

        assert_eq!(a, b);
        assert_eq!(a, c);
        assert_eq!(a, d);
    }
}

lib.rs

ChannelFile

Answer 2

让我们回顾一下功能实现！

内存分配

此处提出的功能样式的主要问题之一是传递给map方法的闭包，该方法分配了许多 。在收集每个字符之前，先将其映射到String。

它还使用format机制，该机制相对较慢。

有时候，人们为了获得“纯粹的”功能性解决方案而努力尝试，而不是：

let mut result = String::new();
for (c, group) in &source.chars().group_by(|&c| c) {
    let count = group.count();
    if count > 1 {
        result.push_str(&count.to_string());
    }

    result.push(c);
}

大约很冗长，但仅在count > 1分配时才分配，就像您的解决方案一样，也不使用format机器。

与完整功能的解决方案相比，我期望性能会大幅度提高，与此同时，与完整的命令性解决方案相比，仍将利用group_by来提高可读性。有时，您应该混搭！