功能编程，在哪些方面效率低下，为什么难以确定空间和时间成本？

Question

我一直在阅读函数式编程，我有两个问题，希望有人可以帮助我。

1. 我已经读过，如果您经常访问相同的数据，懒惰的函数式程序可能效率低下，因为检查表达式是否已被评估的额外开销。我还在下面的线程（Are functional programming languages suitable for graphics programming?）的第一个答案中读到，函数式编程在图形编程的上下文中可能是资源需求，因为它创建了许多临时对象（我认为这与创建新对象来模拟状态？）。

是否有其他领域的功能编程可能最终导致资源沉重/效率低下与OOP /程序编程相比？

1. 我已经在下面的帖子（Pitfalls/Disadvantages of Functional Programming）中读到了第一个答案，那就是＆＃34;很难预测评估懒惰功能程序的时间和空间成本＆＃34;。有人会给出一个简单的（如果存在的话）解释为什么会这样的情况？我认为它只需要在需要时使用惰性求值评估表达式，但为什么预测一种类似于命令式编程的最坏情况类型并不简单呢？

Answer 1

  

我已经读过，如果你经常访问相同的数据，懒惰的函数式程序效率很低，因为检查表达式是否已被评估会产生额外的开销。

这涉及指针上的checking a tag bit。它很便宜。

  

函数式编程在图形编程的上下文中可能需要资源，因为它会创建大量临时对象

这取决于实施。纯FP语言中的分配很便宜，因为不变性意味着您可以避免一些写入障碍。对象分配大致类似于OO语言，尽管某些GC（例如GHC）与例如GHC相比非常有效。 Java的。

  

是否有其他领域的功能编程可能最终导致资源沉重/效率低下与OOP /程序编程相比？

有很多问题需要非常严格的资源使用。例如。操作系统。在这样的环境中，您需要用于直接访问硬件的库以及在适当位置改变内存的能力。根据您正在使用的功能语言实现，您可能有也可能没有。

  

很难预测评估懒惰功能程序的时间和空间成本

对延迟评估成本进行建模是比较困难的，因为完成的工作量和完成时间取决于输入数据，该输入数据仅在运行时可用。

实际上，语言允许您选择是否要使用严格或惰性评估，因为它们都不适合所有情况。