linux与windows频繁打开和关闭文件性能差很远吗?

[Hello_World_01]

我平时在linux环境上做开发时很习惯封装类似如下的文件追加函数，而且性能很高。
int appendfike(...)
{
fopen...
fwrite...
fclose...
...
}
按上面代码移植到vc6或vc2008时发现性能好低呀，追加上万条记录就感觉到很慢了。
但是我改成只打开一次，而写N条记录这样性能却很高。
请问是文件系统不同的原因造成的吗?还是其它原因呀?

[jackyjkchen]

没错，windows为了通用性和可靠性做了许多的妥协（这就是为什么Windows不挑机器，任何PC运行效果都差不多，Linux却对机器挑三拣四，不光是驱动的问题），而且架构的不同导致看上去类似的东西windows的调用层数会更深，做的事情会更多

另一个典型例子就是有人喜欢拿linux的fork和windows的CreateProcess作比较得出linux创建进程比windows快几十倍的结论……去看看Windows Internals，CreateProcess做了多少事情，别说fork了，fork+exec都没CreateProcess做的事多

[jackyjkchen]

有一点是确定的，Windows涉及创建内核资源的API函数（会返回内核对象HANDLE的函数，如fopen内部调用的CreateFile）做的事情比linux系统调用多，速度也慢，这时候尽量减少这种函数的调用是Windows下编程的原则

[qq120848369]

你这封装的也太烂了，写一次打开关闭一次？敢不敢把FILE打开就留下来重复用？

[xunxun]

这个和_commit有关
你如果了解GCC不同平台的实现就知道了

Linux都没这个

[jackyjkchen]

[Quote=引用 4 楼 的回复:]
这个和_commit有关
你如果了解GCC不同平台的实现就知道了

Linux都没这个
[/Quote]

有道理，用Windows就几乎感觉不到延迟写和缓存的存在，比如控制台IO，好像永远是立即回显的

但实际上应该是有缓存的，因为真要禁止了缓存会更慢，你知道这是为什么么

[xunxun]

[Quote=引用 5 楼 的回复:]

引用 4 楼 的回复:
这个和_commit有关
你如果了解GCC不同平台的实现就知道了

Linux都没这个


有道理，用Windows就几乎感觉不到延迟写和缓存的存在，比如控制台IO，好像永远是立即回显的

但实际上应该是有缓存的，因为真要禁止了缓存会更慢，你知道这是为什么么
[/Quote]

我也不是很清楚

我知道这个是以前我发现的GCC在Windows平台性能大衰退的一个io严重bug

debug看了下，_commit这一块儿正好在Win32代码下

后来把这一块儿重写了，用了WriteFile的相关形式

当时查得资料可以参见
http://msdn.microsoft.com/en-us/library/aa364218%28v=VS.85%29.aspx

[Hello_World_01]

大家还有什么补充的答案吗?

[pathuang68]

先将要写入的数据放到一块内存中，积累到了一定数量的时候，一次写入。几乎所有的数据库也都是这么干的，就是在commit的时候，数据才会真正写入到数据库文件中，否则都是在内存里面。在未commit之前，自己虽然可以看到数据表的变化，但是其它的用户是看不到的。

曾经用sqlite3在android手机上做过一个实验，如果每插入一条记录就commit一次（类似楼主的做法），其性能要比插入300条记录，commit一次差好几十倍。

不管是*nix还是windows，楼主的那种做法，效率都不会高，硬盘也会受不了的。

[rendao0563]

千把块就搞定了 你懂的.

[Hello_World_01]

谢谢大家回复
我不了解_commit，能详细说一下吗？

[iaccepted]

这种封装真太差了，即使在linux这样频繁的打开关闭文件（上万次）,先不说效率问题，起码文件本身就很容易坏掉而无法打开。

在linux上也从来不这样写，而是一次打开尽可能完成一次读写操作。

[mars_man]

这就好像所有农民都不去商店买东西了，都各自自己去批发市场买。比起商店进货再销售的方案，不知道浪费多少资源。

[luciferisnotsatan]

[Quote=引用 3 楼 的回复:]

你这封装的也太烂了，写一次打开关闭一次？敢不敢把FILE打开就留下来重复用？
[/Quote]
+1

[cpp618]

如果，把FILE留下来，那要什么时候关闭呢，假如文件时日志文件？