我自己的一个项目，需要同时对65536个文件进行多次写操作。如果先全部打开所有的文件，然后重复写，最后关闭所有的文件。那么第一次写操作全部完成需要16分钟左右，而第二次就需要40分钟了。没有继续测试了。
如果在写操作的时候只打开相应的一个文件，写完关闭。那么所有写操作完成只要2分30秒左右。
由此可见，第二种办法性能要远大于第一种。一次打开所有的文件，需要占用不小的内存，最主要的是.net在处理filestream 的时候，可能要进行大量的内存分配和回收等工作，消耗了大量内存和资源。另外我也做个测试，如果文件数目比较小，那么第一种的性能又要大大好于第二种。
posted on 2006-06-28 08:33 夕阳武士 阅读(1463) 评论(26) 编辑 收藏
不是白痴 都知道 回复 引用
同上 回复 引用
不要人身攻击 回复 引用 查看
我遇到了与楼主同样的问题,也是这样解决的 支持楼上,不要搞人身攻击 回复 引用
技术修养不分高低，只要是自己认真总结的就是好的。支持！ 回复 引用 查看
支持楼上,不要搞人身攻击 回复 引用 查看
我只能说无知者无畏......放在首页就真是................ 回复 引用
说实话可能楼主的表达有点问题，我是这样理解的，一次打开所有文件写没有按照顺序一个一个的打开写速度快：）哈哈，我也是猜得 回复 引用
看来与JAVA相似的性能问题，MS拿到也是个棘手的问题！！！ 回复 引用
硬盘支持多线程读写文件？？？ 回复 引用 查看
我的意思是： 我的第二个方案是， for (int i=0;i<65536;i++) { open; write; close; } 回复 引用 查看
如果文件数目不多，那么采用第一种方案性能要好得多。所以，这仍然是一个值得探讨的问题，楼上有些搞人身攻击的，我只能鄙视。 回复 引用 查看
求求大哥把这样的好东西藏起来，自己没事的时候好好欣赏，一大早就看到这样的破烂东西，让人家感觉我们这里是垃圾场呢！！ 回复 引用
建议关闭匿名讨论！ 回复 引用 查看
建议某些人，先好好学习怎么做人，再去学习其它东西。 回复 引用 查看
我觉得可以使用异步事件来做 回复 引用
回楼上，使用异步事件我考虑过，但是没有做过测试。这与我的应用有关，现在的速度我已经比较满意了，我每次先在内存中生成1G左右的数据，然后写文件。现在文件操作的时间相对已经很少了。 回复 引用 查看
谢谢搂主分享。 有些人不hd呀。 回复 引用 查看
楼上几位搞人身攻击的，把你们的blog地址列出来，让大家看看你们的比楼主写得好多少？ 回复 引用
建议关闭匿名回复！！ 原来说文人相轻，现在程序员相轻并不比文人差，也许不限于文人、程序员，而是国人的通病。 回复 引用 查看
对于那样的评论不用去理会,删除就行了。 回复 引用 查看
@81 那也不用一杆子打翻一船人,看看评论,大多数人还是比较理智的. 一棵树上总是有几片烂叶的,也正如人体一样,偶尔要病一病,抵抗力不会降低.所以,为数不多的反面教材正可以提高总体的素质水平. 回复 引用 查看
支持楼主多发些此累的文章，对某些人的言论大可假装没看见！ 回复 引用
楼主举的例子不大恰当。 你之所以第一个例子当中效率过低，不是因为算法不好，是因为内存不够。 我写了个程序做了测试，在内存足够没有Swap In/Out的前提下，两者的速度基本上是相同的。 可见，之所以楼主的第一种算法慢，是因为积攒在内存中的数据太多，不得不频繁地在虚拟内存之间Swap In/Out 回复 引用 查看
感谢楼上几位的支持，这里理智的人占大多数，已经出乎我的意料，我感到相当满意了。 回复 引用 查看
回smalldust ，不知道你测试数据是否也是65536个文件，我其实本来就用的是第二个方案，后来想到每次频繁打开关闭文件，是否浪费时间，也用程序做了100个文件的测试，性能是第一种方案好，所以我才开始考虑第一种方案的。但是到我具体到应用中，这个方案不适合。 我的内存是2G。每个文件设置的缓存大小是14000，运行起来，本程序占用内存不到1G，机器所有进程占用内存在1900M左右。 第一次等所有文件数据达到缓存大小，开始写操作，花费时间竟然达到了16分钟。第一次写完以后，所有进程的内存还在2G以内。 在第二次写操作的过程中，内存在继续增加，机器所有进程等内存已经超过2048M了。为什么内存还在增加？是不是filestream达到缓存大小还在继续增加缓存？还是需要很多额外的资源来管理这么多filestream对象？这个我不清楚，也没有继续测试。 我的第二个方案实际上先把1G左右的数据保存到内存数组中，然后开始用第二个方案操作。 因为大家不知道我到全部程序代码和应用具体情况，所以出现一些别的理解也是正常的。 回复 引用 查看