函数式编程的开销答案

【问题标题】：Overhead in functional style programming函数式编程的开销
【发布时间】：2014-09-02 17:49:32
【问题描述】：

在Rust by Example #36 中，以命令式和函数式两种方式计算奇数的总和，直至达到极限。

我把这两个分开，把上限增加到10000000000000000，计时结果：

命令式：

me.home:rust_by_example>time ./36_higher_order_functions_a
Find the sum of all the squared odd numbers under 10000000000000000
imperative style: 333960700851149440

real    0m2.396s
user    0m2.387s
sys 0m0.009s

功能风格：

me.home:rust_by_example>time ./36_higher_order_functions_b
Find the sum of all the squared odd numbers under 10000000000000000
functional style: 333960700851149440

real    0m5.192s
user    0m5.188s
sys 0m0.003s

功能版本运行速度较慢，编译时间也稍长。

我的问题是，是什么导致功能版本变慢？这是函数式风格所固有的还是由于编译器没有尽其所能优化？

【问题讨论】：

你必须进行优化编译（rustc -O ...）
当然。函数式风格现在稍微快了一点。

标签： functional-programming compiler-optimization rust imperative-programming

【解决方案1】：

是什么导致功能版本变慢？这是函数式风格所固有的还是由于编译器没有尽其所能优化？

通常，编译器会将较高级别/较短的功能版本转换为命令式编码，作为代码生成的一部分。它还可以应用可提高性能的优化。

如果编译器优化不佳或代码生成器不佳，则功能代码可能比手动编写的版本更差。

这完全取决于编译器。首先启用优化。

【讨论】：