- 主题:像ultraedit那种几百兆的文件秒开是怎么做到的？
mmap的sync有时候很慢，特别是大量小文件时
【 在 z16166 (Netguy) 的大作中提到: 】
: 为啥会有滥用的说法？
: 左手（CRT file io)可以吃饭，右手(os file mapping)也可以吃饭
: 还有第三只手（os file api)
: ...................
--
FROM 111.197.238.250
因为文件大到一定程度，mapping就不全在内存里了，io慢到一定程度，打开整个文件的速度也很受影响
随机访问会让人产生惰性写更差代码
【 在 z16166 的大作中提到: 】
: 为啥会有滥用的说法？
: 左手（CRT file io)可以吃饭，右手(os file mapping)也可以吃饭
: 还有第三只手（os file api)
: ...................
--
FROM 155.64.23.*
特指linux平台的？win上没听说过有这个问题
【 在 jjfz 的大作中提到: 】
: mmap的sync有时候很慢，特别是大量小文件时
:
--
FROM 221.218.161.*
嗯，可能跟NFS有关
程序生成上万的目录，每个目录下几个小文件，sync巨慢
【 在 z16166 (Netguy) 的大作中提到: 】
: 特指linux平台的？win上没听说过有这个问题
--
FROM 111.197.238.250
fread/read的意图（读多少字节）是明确写在参数里的。
mmap则是隐含的。io效率取决于内核的read ahead是否符合你的访问模式。你不用madvise去调整的话，默认策略是为mmap的主要访问场景--映射可执行文件--优化的。
比起fread/read，mmap用起来更需要技巧，最好只用在少数适用的场合。看见“我要io快”就条件反射念出“mmap”，“direct io”，“aio”之类的，说滥用也不冤。
【 在 z16166 的大作中提到: 】
: 为啥会有滥用的说法？
: 左手（CRT file io)可以吃饭，右手(os file mapping)也可以吃饭
: 还有第三只手（os file api)
: ...................
--
FROM 58.37.58.*
看来你们脑海里主要是linux的mmap，我脑海里的主要是win的file mapping
【 在 ilovecpp 的大作中提到: 】
: fread/read的意图（读多少字节）是明确写在参数里的。
: mmap则是隐含的。io效率取决于内核的read ahead是否符合你的访问模式。你不用madvise去调整的话，默认策略是为mmap的主要访问场景--映射可执行文件--优化的。
: 比起fread/read，mmap用起来更需要技巧，最好只用在少数适用的场合。看见“我要io快”就条件反射念出“mmap”，“direct io”，“aio”之类的，说滥用也不冤。
--
FROM 221.218.161.*
这方面两个平台好像差不多吧，你觉得区别是什么？
【 在 z16166 的大作中提到: 】
: 看来你们脑海里主要是linux的mmap，我脑海里的主要是win的file mapping
--
FROM 58.37.58.*
内存映射了解一下
【 在 amony 的大作中提到: 】
:
: 有个需求，几百兆的csv文件，存的都是波形，
: 想快速打开，然后能够拖动浏览，局部放大之类的。
: 有没有现成的可以用的？
--
FROM 223.104.9.*
direct io和预读有时候还是可以优化性能的。
不过确实没有必要啥都mmap
【 在 ilovecpp 的大作中提到: 】
: fread/read的意图（读多少字节）是明确写在参数里的。
: mmap则是隐含的。io效率取决于内核的read ahead是否符合你的访问模式。你不用madvise去调整的话，默认策略是为mmap的主要访问场景--映射可执行文件--优化的。
: 比起fread/read，mmap用起来更需要技巧，最好只用在少数适用的场合。看见“我要io快”就条件反射念出“mmap”，“direct io”，“aio”之类的，说滥用也不冤。
--
FROM 123.115.140.*
windows高性能读写是走iocp，raid、san等情况下乱序读的性能最高，打满底层硬件吞吐
【 在 ilovecpp 的大作中提到: 】
: 这方面两个平台好像差不多吧，你觉得区别是什么？
--
FROM 123.115.140.*