- 主题:像ultraedit那种几百兆的文件秒开是怎么做到的？
filemap是现代OS对文件操作的实现方式，是实际的底层操作。fseek是远古时代OS的顺序读取方式，现在是作为兼容层存在的。
你可以看看nt源代码，文件，cache，虚拟内存这些玩意底层最后都是一套代码
【 在 ilovecpp 的大作中提到: 】
: memmap就是纯扯淡，这个场景fseek一下就能慢了？
--
FROM 27.91.71.*
怕其他用户同时访问文件的话是个打开权限的问题，这个问题在mswin上还是比较严格的，用trick删除已打开文件甚至被视为安全漏洞。
当然我个人也是反对滥用map的，因为很多时候文件并不存放在一个可以高速map的介质上。
【 在 vonNeumann 的大作中提到: 】
: 对于用户态程序，没有特别需求的时候，仍然应该以 fread/fseek/read/lseek 这一套“远古”接口为首选。
: 用 mmap 并不一定能让你程序变快（用不好还会变慢），而且除非你能 100% 保证你的程序运行时不会有其他进程去修改文件，否则很容易在不可预知的时候 SIGBUS。
:
--
FROM 155.64.23.*
因为文件大到一定程度，mapping就不全在内存里了，io慢到一定程度，打开整个文件的速度也很受影响
随机访问会让人产生惰性写更差代码
【 在 z16166 的大作中提到: 】
: 为啥会有滥用的说法？
: 左手（CRT file io)可以吃饭，右手(os file mapping)也可以吃饭
: 还有第三只手（os file api)
: ...................
--
FROM 155.64.23.*
不关闭改名或者删除这个特性，在一致性检查上是个大坑
比如你写doc1，忘关编辑器整理移动文件，最后以为开着的那个doc1没用，又改写成了doc2
【 在 eGust 的大作中提到: 】
: linux 和 win 对文件的处理差别极大，加上 ntfs 跟 linux 上主流的文件系统也差别极大，具体哪个环节出问题的确是不好说。win 平台文件是内核对象，任何操作都重了许多，关闭之前很多其他操作做不了，既慢又条条框框多，出问题的概率自然就低了。
:
--
FROM 155.64.23.*
filemapping就是内核section对象，本质上说nt架构的所有线性空间，都是pagefile上的section，一套代码过来的
Linux的文件操作不一定会从mapping这个层面走一遍，nt的话是一定的
【 在 z16166 的大作中提到: 】
: file mapping在win上使用，从没听到有人诟病说不该（滥）用，pe loader使用，notepad也使用，大量的第三方软件也使用。
: 楼上有位说linux上map小文件有性能问题，怀疑是下面的文件系统的问题，这不应该是file mapping的锅。
:
--
FROM 155.64.23.*