使用.NET进行大量调用，而不是编写简单简洁的方法

Question

我正在阅读“.NET应用程序中的性能提示和技巧”，这是一页由微软创建的文档。文档中提到的技巧之一是进行大量调用，这是执行多个任务的函数调用，而不是执行简单任务的函数调用。其基本原理是，聊天调用可能需要多个调用，而您可以调用一个庞大的方法一次，它会执行多项任务。

我有点搞不懂这是否与我一直在学习的关于写作方法和类的原则相矛盾，这些方法和类做得很好，而不是很多不同的东西。这个原则是否更好地留给可以相互连接的UNIX模块呢？还是我们应该专注于编写简单、可重用的方法和函数，并且只做一件事情，而不是多件事情呢？如果是这样的话，那么通过大量调用而不是喋喋不休的调用来获得更好的性能是否是一个缺陷？或者，这个原则仅仅是为了使代码更具可读性和可维护性，而不是高性能呢？

我所指的文档可以在这里找到- https://msdn.microsoft.com/en-us/library/ms973839.aspx

诚挚的问候,

HandleThatError

Answer 1

这个建议特别适用于异常昂贵的电话，

重要的是，在方法之间进行大量的调用，而不是通过方法进行频繁的调用，因为这些方法的开销高于简单的AppDomain方法调用。 P/Invoke、互操作和远程调用都会带来开销…

它仍然适用。那些东西当时很慢，现在很慢，而且可能永远都慢。

这不是一个一般的设计准则，微小的正常功能通常会被内联。

Answer 2

你首先要注意的是这份文件是14年前写的。自那时以来，计算领域以及最佳实践都发生了很大变化。

您应该知道的第二件事是，本文涉及的是从低级函数中提取出绝对最好的性能。只有当您已经编写了一个设计良好的应用程序，并且发现它执行得太慢时，您才会这样做，并且您需要采取过度的措施来提高性能。

您应该知道的第三件事是，硬件和网络性能自2001年以来呈几何级数增长，而且在大多数情况下，在处理具有多核和千兆字节的4Ghz处理器时，所讨论的性能问题已经不再重要。

您应该知道的第四件事是，自.NET版本1以来，编译器和JIT优化器已经取得了很大进展，本文中提到的许多内容要么不再适用，要么在大多数代码中并不是一个真正的因素。

这篇文章还适用吗？也许在某些情况下..。但你真的不应该用它作为设计灵感。和往常一样，正确地设计应用程序，并且只有当你分析了你的代码并发现瓶颈是实际问题时才进行优化。

Answer 3

把事情分解成小函数，因为

1. 他们是独立的和单位可测试的大部分。
2. 它们可以重复使用。
3. 如果命名正确，将使代码更好地理解。
4. 由于较小函数之间的关系较少，编译器可以更好地优化发布代码。