我有大量的音频文件，我正在通过处理算法尝试从中提取某些数据位（即：整个剪辑的平均音量）。我有许多构建脚本，它们以前从 Samba 网络共享中提取输入数据，我已经创建了一个到 via net use（即：）的网络驱动器映射M: ==> \\server\share0。
现在我有了一个新的 1TB 大容量 SSD，我可以将文件存储在本地并非常快速地处理它们。为了避免大量重写我的处理脚本，我删除了我的网络驱动器映射，并使用localhost主机名重新创建它。即：M: ==> \\localhost\mydata。
当我使用这种映射时，我是否会冒着产生重大开销的风险，例如数据必须通过 Windows 网络堆栈的一部分，或者操作系统是否使用任何快捷方式，因此它或多或少等同于直接磁盘访问（即：机器是否知道它只是从自己的硬盘驱动器中提取文件）。延迟增加并不是我关心的问题，但最大持续平均吞吐量至关重要。
我问这个是因为我正在决定是否应该修改我的所有处理脚本以使用不同的网络路径样式。
额外问题：Linux 主机是否同样适用：它们是否足够聪明，可以知道它们是从本地磁盘中提取的？
当我使用这样的映射时，我是否冒着产生重大开销的风险，
是的。通过使用 UNC 路径 ( \\hostname\sharename\filename) 而不是本地路径 ( [\\?\]driveletter:\directoryname\filename)，您可以让所有流量通过服务器消息块协议 (SMB / Samba) 发生。这通常会在磁盘访问和访问时间方面增加显着的开销。
网络上的流程是这样的：
Application -> SMB Client -> Network -> SMB Server -> Target file system
现在通过将文件移动到本地计算机，但仍使用 UNC 访问它们，流程如下：
Application -> SMB Client -> localhost -> SMB Server -> Target file system
您最小化的唯一一件事（没有消除，到 localhost 的 SMB 流量仍然涉及网络层以及所有相关的计算和流量）是网络流量。
此外，鉴于 SMB 是专门为网络流量量身定制的，它的读取可能无法以最佳方式使用您的磁盘和操作系统的缓存。例如，它可能以特定大小的块执行读取，而您的磁盘在读取其他大小的块时执行得更好。
如果您想要最佳吞吐量和最短访问时间，请尽可能少地使用中间层，在这种情况下，通过直接访问文件系统：
Application -> Target file system
确保使用 TCP 通过直接文件访问，即使使用“环回”，在 Linux 和 Windows 上也会产生诸如路由、内存分配等开销，是的，环回设备是非物理内核设备，比其他网络设备快，但不比其他网络设备快直接文件访问。据我所知，在 Windows 上还有其他环回优化，例如 NetDNA 和“Fast TCP Loopback”。
我假设环回设备的瓶颈将是内存（复制）进程。因此，直接访问文件而不是通过回送设备在 linux 和 windows 上总是更快（并且资源消耗低）。
此外，这两个操作系统都通过 Windows 上的“命名管道”和 linux 上的“unix 域套接字”解决了 IPC 的协议开销，使用这些也将比在适用时使用环回设备更快。