我们的日志记录类在初始化时会将日志文件截断为 500,000 字节。从那时起，日志语句将附加到文件中。
我们这样做是为了降低磁盘使用率，我们是一种商品最终用户产品。
显然保留前 500,000 个字节没有用，所以我们保留最后 500,000 个字节。
我们的解决方案存在一些严重的性能问题。有什么有效的方法来做到这一点？
【问题讨论】：
“我可能会创建一个新文件，在旧文件中查找，从旧文件到新文件进行缓冲读/写，将新文件重命名为旧文件。”
我认为你最好还是简单点：
#include <fstream>
std::ifstream ifs("logfile"); //One call to start it all. . .
ifs.seekg(-512000, std::ios_base::end); // One call to find it. . .
char tmpBuffer[512000];
ifs.read(tmpBuffer, 512000); //One call to read it all. . .
ifs.close();
std::ofstream ofs("logfile", ios::trunc);
ofs.write(tmpBuffer, 512000); //And to the FS bind it.
这可以避免文件重命名，只需将最后的 512K 复制到缓冲区，以截断模式打开日志文件（清除日志文件的内容），然后将相同的 512K 吐回到文件的开头。
请注意，上面的代码还没有经过测试，但我认为这个想法应该是合理的。
您可以将 512K 加载到内存中的缓冲区中，关闭输入流，然后打开输出流；这样，您将不需要两个文件，因为您输入、关闭、打开、输出 512 个字节，然后继续。您可以通过这种方式避免重命名/文件重定位魔法。
如果您在某种程度上不反对将 C 与 C++ 混合使用，您也可以：
（注意：伪代码；我不记得我脑海中的 mmap 调用）
int myfd = open("mylog", O_RDONLY); // Grab a file descriptor
(char *) myptr = mmap(mylog, myfd, filesize - 512000) // mmap the last 512K
std::string mystr(myptr, 512000) // pull 512K from our mmap'd buffer and load it directly into the std::string
munmap(mylog, 512000); //Unmap the file
close(myfd); // Close the file descriptor
取决于很多事情，mmap 可能比寻找更快。如果你好奇的话，谷歌搜索“fseek vs mmap”会产生一些有趣的信息。
HTH
【讨论】：
我可能会：
要做前三个步骤（省略了错误检查，例如，如果文件小于 500k 大，我不记得 seekg 做了什么）：
#include <fstream>
std::ifstream ifs("logfile");
ifs.seekg(-500*1000, std::ios_base::end);
std::ofstream ofs("logfile.new");
ofs << ifs.rdbuf();
那么我认为你必须做一些非标准的事情来重命名文件。
很明显，您需要 500k 的可用磁盘空间才能使其正常工作，因此，如果您截断日志文件的原因是因为它刚刚填满了磁盘，那就不好了。
我不确定为什么搜索速度很慢，所以我可能会遗漏一些东西。我不希望寻找时间取决于文件的大小。可能取决于文件，我不确定这些函数是否在 32 位系统上处理 2GB+ 文件。
如果复制本身很慢，那么根据平台的不同，您可能可以通过使用更大的缓冲区来加速它，因为这减少了系统调用的次数，也许更重要的是减少了磁盘磁头必须寻找的次数在读点和写点之间。为此：
const int bufsize = 64*1024; // or whatever
std::vector<char> buf(bufsize);
...
ifs.rdbuf()->pubsetbuf(&buf[0], bufsize);
用不同的值测试它，看看。您也可以尝试增加 ofstream 的缓冲区，我不确定这是否会有所作为。
请注意，在“实时”日志文件上使用我的方法很麻烦。例如，如果在副本和重命名之间附加了一个日志条目，那么您将永远丢失它，并且您尝试替换的文件上的任何打开句柄都可能导致问题（它会在 Windows 和 linux 上失败）将替换文件，但旧文件仍会占用空间并仍会被写入，直到句柄关闭）。
如果截断是从执行所有日志记录的同一线程完成的，那么没有问题，您可以保持简单。否则，您将需要使用锁或其他方法。
这是否完全健壮取决于平台和文件系统：移动和替换可能是也可能不是原子操作，但通常不是，因此您可能必须重命名旧文件，然后重命名新文件，然后删除旧文件，并进行错误恢复，在启动时检测是否有重命名的旧文件，如果有，将其放回并重新启动截断。 STL 无法帮助您处理平台差异，但有 boost::filesystem。
抱歉，这里有很多警告，但很大程度上取决于平台。如果您在 PC 上，那么我很奇怪为什么复制区区 0.5 兆的数据需要任何时间。
【讨论】：
如果您碰巧使用 Windows，请不要费心复制零件。只需调用 FSCTL_SET_SPARSE 和 FSCTL_SET_ZERO_DATA 告诉 Windows 您不再需要第一个字节
【讨论】：
如果您可以在重新初始化之间生成几 GB 的日志文件，那么似乎仅在初始化时截断文件并没有真正的帮助。
我认为我会尝试提出一种专门的文本文件格式，以便始终将内容替换到位，并带有指向“当前”行的指针。您将需要一个恒定的线宽来仅分配一次磁盘空间，并将指针放在该文件的第一行或最后一行。
这样，文件将永远不会增长或缩小，并且您将始终拥有最后 N 个条目。
N=6 的插图（“|”表示空格填充直到那里）：
#myapp 日志文件，行 = 6，宽度 = 80，指针 = 4 | [2008-12-01 15:23] foo烤蛋糕| [2008-12-01 16:15] foo 烤好了蛋糕 | [2008-12-01 16:16] foo 吃蛋糕 | [2008-12-01 16:17] foo告诉bar：我给你做了蛋糕，但是我吃过了| [2008-12-01 13:53] 酒吧想点蛋糕| [2008-12-01 14:42] bar 告诉 foo：sudo 给我烤个蛋糕 |
【讨论】：
另一种解决方案是让日志记录类检测日志文件大小何时超过 500k，然后打开一个新的日志文件，然后关闭旧的。
然后日志类会查看旧文件，并删除最旧的文件
记录器有两个配置参数。
这样，日志文件管理将是一个自我维护的事情。
【讨论】：
所以你想要文件的结尾——你把它复制到某种缓冲区来做什么？你是什么意思'写回'到文件中。你的意思是它覆盖了文件，在初始化时将原始文件截断为 500k 字节+它添加了什么？
建议：
重新思考你在做什么。如果这行得通并且是所期望的，那么它有什么问题？为什么要改变？有性能问题吗？您是否开始想知道所有日志条目都去了哪里？对于此类问题，提供比发布现有行为更多的问题最有帮助。除非他们知道完整的问题，否则没有人可以对此发表完全评论——因为它是主观的。
如果是我和我的任务是重新设计你的日志记录机制，我会建立一个机制来将日志文件截断为：时间长度或大小。
【讨论】：
我认为这与计算机无关，而是你们如何编写日志记录类。你把最后的 500k 读成一个字符串对我来说听起来很奇怪，你为什么要这样做？
只需附加到日志文件。
fstream myfile;
myfile.open("test.txt",ios::app);
【讨论】：
Widefinder 2 has a lot of talk about efficient IO available（或者更准确地说，“备注”列下的链接有很多关于可用高效 IO 的信息）。
回答你的问题：
标准库在文件系统操作方面有些限制。如果您不限于标准库，您可以很容易地过早结束文件（也就是说，说“此点之后的所有内容都不再是该文件的一部分”），但很难晚启动文件（“所有内容在此之前不再是此文件的一部分”）。
简单地在文件中寻找 500,000 字节然后开始缓冲复制到新文件会很有效。但是一旦你这样做了，标准库就没有现成的“重命名这个文件”功能。本机操作系统函数可以高效地重命名文件，Boost.Filesystem 或 STLSoft 也可以。
std::string，然后将其写回文件。在这种情况下，您将删除文件的最后一位，并且在标准库之外很容易做到这一点。只需使用文件系统操作将文件大小设置为 500,000 字节（例如，ftruncate、SetEndOfFile）。之后的任何内容都将被忽略。
【讨论】：