cats 和 scalaz 是否会对应用程序产生性能开销？
Do cats and scalaz create performance overhead on application?
我知道这完全是一个无意义的问题，但由于我对编程技能的文盲，我想到了这个问题。
使用 Cats 和 scalaz 以便我们可以在 Scala 中编写类似于 Haskell/in 纯函数式编程方式的代码。但是为了实现这一点，我们需要在我们的项目中额外添加这些库。最终为了使用它们，我们需要用它们的对象和函数来包装我们的代码。它是添加额外代码和依赖项的东西。
我不知道这些是否会在内存中创建更大的对象。
这些都让我思考。所以我的问题是：如果我使用 cats/scalaz ，我会遇到任何性能问题，比如更多的内存消耗吗？
或者，如果我的应用程序需要性能，我应该避免这些吗？
Do cats and scalaz create performance overhead on application?
绝对。
任何一行代码都会增加性能开销。
所以，如果这是您的顾虑，那么请不要编写任何代码 （嗯，实际上，如果我们从未尝试过所有这些，世界可能会更简单）.
现在，在外面回答。您应该问的正确问题是：“X 库的开销是否对我的软件有害？”；请记住，这适用于任何库，实际上适用于您编写的任何代码，适用于您选择的任何算法等。
而且，为了回答这个问题，我们需要一些东西。
- 定义您正在编写的软件必须遵守的 SLA。没有这些，您提出的任何性能问题/观察都是毫无意义的。如果您不知道这对您和您的客户是否有意义，那么快/慢并不重要。
- 获得 SLA 后，您需要执行压力测试以验证您当前的软件版本是否满足这些要求。因为，如果您当前的代码性能足够好，那么您应该担心其他事情，例如可维护性、测试、添加更多功能等。
PS：请记住，这些 SLA 不应是原始数字，而应以百分位数表示，测试结果也是如此。
- 当您发现您的 SLA 下降时，您需要进行适当的基准测试和调试以确定项目的瓶颈。如您所见，必须在每一行代码上关注性能，但这是一项通常不会产生任何相关输出的大量工作。因此，我们不是评估所有的性能，而是首先找到瓶颈，那些对软件整体性能贡献最大的小代码 （记住 Pareto 原则）。
请记住，在这一步中，我们必须是不可或缺的，网络也很重要。 （你会看到最后一个通常是最大的减速；因此，通常你宁愿搜索架构解决方案，比如使用 Fibers 而不是 Threads 而不是尝试优化小功能. 此外，有时更简单、更便宜的解决方案是更好的基础设施）.
- 当您找到瓶颈时，您需要制定一些备选方案，实施这些备选方案，不仅要对它们进行基准测试，还要进行统计假设检验以验证所提议的更改是否值得。当然，还要验证它们是否足以满足 SLA。
因此，如您所见，表演是一门艺术，需要大量的工作。因此，除非您致力于完成所有这些，否则不要再担心您无法正确衡量和优化的事情。
相反，专注于提高代码的可维护性。这实际上也有助于提高性能，因为当您发现需要更改某些内容时，您会感激代码尽可能干净并且代码的整个体系结构允许轻松更改。
而且，相信我，当我这么说时，使用 cats、cats-effect、fs2，等将在这方面有所帮助。此外，它们实际上在核心上进行了相当优化，因此您应该适合很多用例。
现在，最大的例外是，如果您知道您正在做的工作将非常 CPU 并且内存受限，那么是的，您几乎可以确定所有这些抽象都是有害的。在这些情况下，您甚至可能希望远离 JVM，而是使用 Rust 这样的语言编写相当低级的代码，这将提供您拥有解决此类问题的适当工具，并且仍然比普通的旧 C.
更安全
我知道这完全是一个无意义的问题，但由于我对编程技能的文盲，我想到了这个问题。 使用 Cats 和 scalaz 以便我们可以在 Scala 中编写类似于 Haskell/in 纯函数式编程方式的代码。但是为了实现这一点，我们需要在我们的项目中额外添加这些库。最终为了使用它们，我们需要用它们的对象和函数来包装我们的代码。它是添加额外代码和依赖项的东西。 我不知道这些是否会在内存中创建更大的对象。 这些都让我思考。所以我的问题是：如果我使用 cats/scalaz ，我会遇到任何性能问题，比如更多的内存消耗吗？ 或者，如果我的应用程序需要性能，我应该避免这些吗？
Do cats and scalaz create performance overhead on application?
绝对。
任何一行代码都会增加性能开销。
所以，如果这是您的顾虑，那么请不要编写任何代码 （嗯，实际上，如果我们从未尝试过所有这些，世界可能会更简单）.
现在，在外面回答。您应该问的正确问题是：“X 库的开销是否对我的软件有害？”；请记住，这适用于任何库，实际上适用于您编写的任何代码，适用于您选择的任何算法等。
而且，为了回答这个问题，我们需要一些东西。
- 定义您正在编写的软件必须遵守的 SLA。没有这些，您提出的任何性能问题/观察都是毫无意义的。如果您不知道这对您和您的客户是否有意义，那么快/慢并不重要。
- 获得 SLA 后，您需要执行压力测试以验证您当前的软件版本是否满足这些要求。因为，如果您当前的代码性能足够好，那么您应该担心其他事情，例如可维护性、测试、添加更多功能等。
PS：请记住，这些 SLA 不应是原始数字，而应以百分位数表示，测试结果也是如此。 - 当您发现您的 SLA 下降时，您需要进行适当的基准测试和调试以确定项目的瓶颈。如您所见，必须在每一行代码上关注性能，但这是一项通常不会产生任何相关输出的大量工作。因此，我们不是评估所有的性能，而是首先找到瓶颈，那些对软件整体性能贡献最大的小代码 （记住 Pareto 原则）。
请记住，在这一步中，我们必须是不可或缺的，网络也很重要。 （你会看到最后一个通常是最大的减速；因此，通常你宁愿搜索架构解决方案，比如使用Fibers而不是Threads而不是尝试优化小功能. 此外，有时更简单、更便宜的解决方案是更好的基础设施）. - 当您找到瓶颈时，您需要制定一些备选方案，实施这些备选方案，不仅要对它们进行基准测试，还要进行统计假设检验以验证所提议的更改是否值得。当然，还要验证它们是否足以满足 SLA。
因此，如您所见，表演是一门艺术，需要大量的工作。因此，除非您致力于完成所有这些，否则不要再担心您无法正确衡量和优化的事情。 相反，专注于提高代码的可维护性。这实际上也有助于提高性能，因为当您发现需要更改某些内容时，您会感激代码尽可能干净并且代码的整个体系结构允许轻松更改。
而且，相信我，当我这么说时，使用 cats、cats-effect、fs2，等将在这方面有所帮助。此外，它们实际上在核心上进行了相当优化，因此您应该适合很多用例。
现在，最大的例外是，如果您知道您正在做的工作将非常 CPU 并且内存受限，那么是的，您几乎可以确定所有这些抽象都是有害的。在这些情况下，您甚至可能希望远离 JVM，而是使用 Rust 这样的语言编写相当低级的代码，这将提供您拥有解决此类问题的适当工具，并且仍然比普通的旧 C.
更安全