有没有更好的方法来覆盖文件内容? [英] Is there a better way to overwrite file contents?

问题描述

我正在寻找覆盖已存在文件的内容.显然，按照此答案，我可以创建一个覆盖旧文件的新文件.但是，我正在编写一个可能多次执行此操作的程序，我想尽可能减少不必要的开销.

I'm looking to overwrite the contents of a file that already exists. Obviously I could just create a new file that overwrites the old one, as per this answer. However, I'm writing a program that is going to be doing this potentially quite a few times, and I want to cut down unnecessary overhead as much as possible.

所以我的问题是:是否有更好的方法来简单地重写文件本身的内容，而不是编写替代旧文件的新"文件?还是简单地覆盖整个文件内容的开销大约等于创建新文件然后写入的开销? (出于记录目的，这些文件只有1 KB大.)

So my question is: is there a better way of simply rewriting the contents of the file itself, instead of writing a 'new' file that replaces the old one? Or is the overhead of simply overwriting the entire file contents roughly equivalent to the overhead of creating the new file and then writing to it? (For the record, these files are only 1 KB large.)

推荐答案

简短的答案:编写个人资料和个人资料.

The short answer: write both and profile.

挥舞着长长的答案:

覆盖文件将涉及以下系统调用:

Overwriting a file will involve the following system calls:

open
write
close

创建新文件，删除旧文件并重命名新文件将涉及以下系统调用:

Creating a new file, deleting the old file, and renaming the new file will involve the following system calls:

open
write
close
unlink
rename

系统调用通常是程序中最慢的部分.通常，减少系统调用是加快程序速度的好方法.覆盖一个文件将重新使用操作系统的内部目录条目数据；这可能还会带来一些速度上的改进. (使用带有VM开销的语言来衡量它们可能很难...)

System calls are often the slowest part of programs; in general, reducing system calls is a good way to speed a program. Overwriting the one file will re-use the operating system's internal directory entry data; this will probably also lead to some speed improvements. (They may be difficult to measure in a language with VM overhead...)

您的文件很小，因此每个原子write()都应进行原子处理，假设您要在一次写入中更新整个1K. (因为您关心性能，所以这似乎是一个安全的假设.)这确实意味着，除非发生灾难性的电源故障和有损安装选项，否则其他进程不应看到 partial 写入. (不常见.)即使面对多次写入，文件重命名方法也能提供一致的文件.

Your files are small enough that each write() should be handled atomically, assuming you're updating the entire 1K in a single write. (Since you care about performance, this seems like a safe assumption.) This does mean that other processes should not see partial writes except in the case of catastrophic powerfailures and lossy mount options. (Not common.) The file re-name approach does give consistent files even in the face of multiple writes.

但是，1K文件是一种效率很低的存储机制.许多文件系统将沿着4k块写入文件.如果这些数据块仅存在于您的应用程序中，可能有必要一次将它们写在某种类型的容器中. (Quake派生的系统这样做是为了从zip文件中读取其地图，纹理等，因为巨大的流IO请求远远快于成千上万个较小的IO请求.)当然，如果您的应用程序正在编写，则这样做会更加困难这些文件供其他应用程序使用，但是如果文件很少共享，则仍然值得调查.

However, 1K files are a pretty inefficient storage mechanism; many filesystems will write files along 4k blocks. If these data blocks exist only in your application it might make sense to write them in containers of some sort, several at a time. (Quake-derived systems do this for reading their maps, textures, and so forth, out of zip files, because giant streaming IO requests are far faster than thousands of smaller IO requests.) Of course, this is harder if your application is writing these files for other applications to work with, but it might still be worth investigating if the files are rarely shared.

这篇关于有没有更好的方法来覆盖文件内容?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！