我被告知我的库比应有的速度慢，解析特定文件（文本文件，大小 326 kb）的速度要慢 30 倍以上。用户建议可能是我用的是std::ifstream（大概不是FILE）。
我不想盲目地重写，所以我想我先在这里检查一下，因为我的猜测是瓶颈在其他地方。我正在逐字阅读，所以我使用的唯一函数是get()、peek() 和tellg()/seekg()。
更新：
我进行了分析，并得到了confusing 输出 - gprof 似乎并不认为它花了这么长时间。我重写了程序，首先将整个文件读入缓冲区，它的速度提高了大约 100 倍。我认为问题可能是 tellg()/seekg() 花了很长时间，但 gprof 可能由于某种原因无法看到。在任何情况下，ifstream 似乎没有缓冲整个文件，即使对于这个大小。
【问题讨论】：
标签： c++ optimization file-io ifstream
Here 是一个出色的基准，它表明在极端条件下，fstreams 实际上非常慢......除非：
FILE* 没有太大区别。不过，您不应该过早地进行优化。 fstreams 通常更好，如果您需要在以后优化它们，您可以稍后再做，而且成本很低。为了提前做好最坏的准备，我建议现在为fstream 创建一个最小代理，以便您以后可以对其进行优化，而无需触及任何其他内容。
【讨论】：
我认为您的问题不太可能通过从 fstream 切换到 FILE* 来解决，通常两者都由 C 库缓冲。操作系统也可以缓存读取（Linux 在这方面非常好）。鉴于您正在访问的文件的大小很可能它会完全在 RAM 中。
就像 PolyThinker 所说，最好的办法是通过分析器运行程序以确定问题出在哪里。
此外，如果您的磁盘碎片严重，这可能会导致明显的延迟，因为第一次读取文件时磁盘必须将磁头移动到正确的位置。
【讨论】：
我同意你应该配置文件。但是，如果您一次读取一个字符的文件，那么创建一个内存映射文件怎么样？这样，您可以将文件视为字符数组，并且操作系统应该为您处理所有低级缓冲。最简单且可能最快的解决方案是我书中的胜利。 :)
【讨论】：
所有基准都是邪恶的。只需针对您期望的数据分析您的代码即可。
我在 Ruby、Python、Perl、C++ 之间进行了一次 I/O 性能比较。对于我的数据、语言版本等，C++ 的变体慢了好几倍（当时这是一个很大的惊喜）。
【讨论】：
我认为这不会有什么不同。尤其是当您逐个字符地读取时，I/O 的开销可能会完全支配任何东西。 为什么一次读取单个字节？你知道它的效率有多低吗？
对于 326kb 的文件，最快的解决方案很可能是一次将其读入内存。
std::ifstream 和 C 等效项之间的区别基本上是一个或两个虚函数调用。如果每秒执行几千万次，可能会有所不同，否则，就不是真的。文件 I/O 通常很慢，以至于用于访问它的 API 并不重要。更重要的是读/写模式。很多查找都是不好的，顺序读/写是好的。
【讨论】：
应该会慢一些，但就像你说的，它可能不是瓶颈。你为什么不分析你的程序，看看是不是这样？
【讨论】：