文件修改的时间复杂度？答案

【问题标题】：Time complexity of file modification?文件修改的时间复杂度？
【发布时间】：2016-09-08 14:31:44
【问题描述】：

这些文件修改的时间复杂度（相对于文件大小）是多少？

我希望覆盖和追加都很快。如果文件的结构类似于 C++ 的deques，我可以看到前置足够快，但我从未见过允许低级前置的语言。我怀疑在中间插入是否很快，尽管我想有一些数据结构可以使它更快。

【问题讨论】：

时间复杂度本身没有“快”或“慢”之分。这也是一个有点奇怪的问题，因为这些高度依赖于硬件、文件系统等等。
答案至少部分取决于操作系统是否支持非连续文件。
@Sami 它们不作为技术术语存在（尽管“超快”实际上是数值分析中的技术术语），但我显然没有将它们用作技术术语。取决于规格的问题只是意味着一个很好的答案将讨论最常见的规格如何处理它，而一个特殊的答案将讨论那里还有什么。

【解决方案1】：

在大多数文件系统中：

插入的 O(n + m) 是最坏的情况。当您插入文件时，您必须将文件中当前的所有字节从插入点向下移动，以便为要插入的 n 个字节创建一个孔。所以如果你有：

This is a test system.

而你想在“测试”之后插入“紧急广播”，那么你首先要为插入的文字打一个洞：

This is a test                            system.

然后插入新文本：

This is a test of the emergency broadcast system.

这样，文件在概念上非常像数组。如果你想在前面或中间插入一些东西，你必须为它打一个洞。如果你想删除一些东西，你必须填补空白。

有一些文件系统可以让您将不连续的块中的文件修补在一起。也就是说，你可以有这样的逻辑：

<pointer to "This is a test" chunk>
<pointer to "of the emergency broadcast" chunk>
<pointer to "system." chunk>

文件系统会根据需要负责拆分和合并块。这些文件系统并不罕见，但普通程序通常不会使用该功能。

【讨论】：

您是否有文件内容的来源/参考在大多数文件系统中被视为数组？
@leewz：我没有说文件系统将文件内容视为数组。我说过，从概念上讲，您可以考虑以与在数组中执行操作的方式大致相同的方式进行前置、添加、覆盖和附加。文件系统通常有两种访问模式：顺序访问，其中文件在概念上是一个流，或者随机访问，其中文件更像是一个数组。请参阅任何文件系统 API 参考以验证这一点。大多数编程语言的 I/O 库都有顺序访问方法和随机访问方法。