TD; DR：
关于我在问的问题有些困惑，所以这是问题背后的驱动思想：
我一直希望这个问题是什么。我本来可能说得不太好。但是其意图一直是“ 模块化，分离，松散耦合，解耦，重构的代码 ”，其本质明显比“ 整体式单一单元，在一个地方完成所有工作，一个文件，紧密耦合的 ”代码慢。剩下的只是我当时或现在或以后会遇到的细节和各种表现形式。在某种程度上，它肯定较慢。就像无碎片磁盘一样，您必须从任何地方拾起碎片。慢一点 当然。但是我应该在乎吗？
问题不在于...
与微优化，过早优化等无关。这与“优化这一部分或死亡”无关。
之后怎么样了？
它涉及随着时间而出现的有关编写代码的总体方法，技术和思考方式：
- “将此代码作为依赖项注入到您的类中”
- “每个班级写一个文件”
- “将视图与数据库，控制器，域分开”。
- 不要编写意大利面同质的单个代码块，而是编写可以协同工作的许多单独的模块化组件
它是关于在十年内当前在大多数框架中看到和倡导的代码的方式和样式，这些框架是在大会上倡导的，并且是通过社区传播的。这是思维方式从“整体块”到“微服务”的转变。随之而来的是机器级别的性能和开销，以及一些程序员级别的开销。
原始问题如下：
在计算机科学领域，我注意到编程方面的思维方式发生了显着变化。我经常遇到这样的建议：
- 编写较小的函数式代码（这种方式更具可测试性和可维护性）
- 将现有代码重构为越来越小的代码块，直到大多数方法/函数只有几行长并且很清楚它们的目的是什么（与更大的整体块相比，它创建了更多函数）
- 编写只做一件事的函数-关注点分离等（通常会在堆栈上创建更多函数和更多帧）
- 创建更多文件（每个文件一个类，用于分解目的的更多类，用于诸如MVC，域架构，设计模式，OO等层的目的，这会创建更多文件系统调用）
与“旧”或“过时”或“意大利面条”编码实践相比，这是一个变化，在常规编码实践中，您的方法跨越2500行，并且大型类和上帝对象可以完成所有工作。
我的问题是这样的：
当涉及到机器代码，1和0，汇编指令以及HDD盘片时，我应该完全担心我的类完全分离的OO代码以及各种重构的小型函数和方法也会生成额外的开销？
细节
尽管我对ASM到底如何处理OO代码及其方法调用以及DB调用和编译器调用如何转换为在HDD磁盘上移动执行器臂的方式并不太熟悉，但我确实有一些想法。我假设每个额外的函数调用，对象调用或“ #include”调用（在某些语言中）都会生成一组额外的指令，从而增加代码量并增加各种“代码接线”开销，而无需添加实际的“有用”代码。我还认为可以在ASM实际上在硬件上运行之前对其进行良好的优化，但是优化也只能做很多事情。
因此，我的问题是-与“包含一个大方法，其中包含一个大方法一切都放在一个整体文件中”，由于这种开销？
为清楚起见，更新：
我假设采用相同的代码并将其拆分，重构，解耦为越来越多的函数，对象以及方法和类将导致越来越多的参数在较小的代码段之间传递。因为可以肯定的是，重构代码必须保持线程运行，并且这需要传递参数。与单个整体类或方法相比，更多的方法，更多的类或更多的Factory Method设计模式导致传递更多信息位的开销更大。
有人说（引用待定），所有代码中多达70％是由ASM的MOV指令组成的-向CPU寄存器加载适当的变量，而不是进行实际的计算。就我而言，您可以使用PUSH / POP指令来加载CPU时间，以提供各种代码之间的链接和参数传递。您编写的代码段越小，所需的“链接”开销就越大。我担心这种联系会增加软件的膨胀和减慢速度，我想知道我是否应该关注这一点，以及是否要关注（如果有的话），因为现在和将来的下一代程序员都在为下个世纪构建软件，则必须使用和使用使用这些做法构建的软件。
更新：多个文件
我现在正在编写新代码，正在逐渐替换旧代码。特别是我注意到旧的类之一是〜3000行文件（如前所述）。现在，它已成为位于各个目录中的15-20个文件的集合，包括测试文件，不包括我用来将某些东西绑定在一起的PHP框架。还有更多文件。对于磁盘I / O，加载多个文件比加载一个大文件要慢。当然，并非所有文件都已加载，它们是根据需要加载的，并且存在磁盘缓存和内存缓存选项，但我仍然相信，这loading multiple files需要比loading a single file内存更多的处理工作。我将其添加到我的关注中。
更新：依赖注入所有内容
过一会儿再说。我认为我的问题被误解了。也许我选择误解了一些答案。我并不是在谈论微优化，因为一些答案已经被挑出来了（至少我认为我所说的关于微优化的说法是用词不当），而是整体上“重构代码以放松紧密耦合”的动向。 ，在代码的每个级别。我是最近从Zend Con来的，这种风格的代码一直是公约的核心和核心内容之一。从视图中解耦逻辑，从模型中解脱视图，从数据库中解脱模型，并且如果可能的话，从数据库中解耦数据。依赖-注入所有内容，有时意味着只添加什么都不做的接线代码（函数，类，样板），但可以用作接缝/勾点，在大多数情况下，很容易使代码大小加倍。
更新2：“将代码分成更多文件”是否会严重影响性能（在所有计算级别上）
哲学如何compartmentalize your code into multiple files影响当今的计算（性能，磁盘利用率，内存管理，CPU处理任务）？
我在说
之前...
在一个假设但还不算太远的过去中，您可以轻松地编写一个文件的单个块，该文件具有模型，视图和控制器意大利面条或未意大利面条编码，但是一旦加载完成就可以运行所有文件。过去使用C代码进行一些基准测试时，我发现将单个900Mb文件加载到内存中并进行大块处理要比加载一堆较小的文件并以较小的和平处理速度更快。最后进行相同的工作。
.. 现在*
今天，我发现自己正在查看显示分类账的代码，该代码具有..如果某项是“订单”等功能，则显示订单HTML块。如果可以复制订单项，请打印HTML块，该块后面显示一个图标和HTML参数，使您可以进行复制。如果可以向上或向下移动项目，则显示适当的HTML箭头。等等，我可以通过Zend Framework创建partial()调用，这实际上意味着“调用一个将参数带入其也会调用的单独HTML文件中的函数”。根据我想获得的详细程度，我可以为分类帐的最细部分创建单独的HTML函数。一个用于向上箭头，向下箭头，一个用于“我可以复制此项目”，等等。轻松创建多个文件只是为了显示网页的一小部分。以我的代码和幕后的Zend Framework代码为例，系统/堆栈可能会调用近20-30个不同的文件。
什么？
我对某些方面感兴趣，这是通过将代码划分为许多较小的单独文件而造成的机器磨损。
例如，加载更多文件意味着使它们位于文件系统的各个位置以及物理HDD的各个位置，这意味着需要更多的HDD查找和读取时间。
对于CPU，这可能意味着更多的上下文切换和加载各种寄存器。
在此子块中（更新＃2），我更严格地关注如何使用多个文件来完成可以在单个文件中完成的相同任务，从而影响系统性能。
使用Zend Form API与简单HTML
我将Zend Form API与最新和最好的现代OO实践一起使用，以构建具有验证的HTML表单，并将其转换POST为域对象。
我花了35个文件才做到。
35 files =
= 10 fieldsets x {programmatic fieldset + fieldset manager + view template}
+ a few supporting files
所有这些都可以用一些简单的HTML + PHP + JS + CSS文件替换，也许总共是4个轻量级文件。
是不是更好？这值得吗？...想象一下，加载35个文件+众多使它们工作的Zend Zramework库文件，而不是4个简单文件。