- 主题:像ultraedit那种几百兆的文件秒开是怎么做到的？
windows下的file mapping就可以只map文件的一部分，按需map。
如果用户一直翻页，可以搞个预读，提前读多一点进来
csv文件是文本行的结构，和文件映射的分块有交叉，需要处理好。
--
修改:z16166 FROM 123.115.163.*
FROM 123.115.163.*
之前有对比测试，提高不了速度。用起来方便点
【 在 ilovecpp (cpp) 的大作中提到: 】
: memmap就是纯扯淡，这个场景fseek一下就能慢了？
:
: 【 在 GoGoRoger 的大作中提到: 】
: : Maping后还涉及渲染的问题吧，不太懂。
--
FROM 123.115.163.*
ctrl + g，跳转到指定的行
不过貌似跟楼主的主要需求关系不大了。
【 在 ilovecpp 的大作中提到: 】
: 并没有什么方便的。场景是文本编辑器，没有随机访问。
--
FROM 221.218.161.*
那你这不是个文本编辑器，是个作图工具
所以，很多时候发帖人没有描述清楚自己的真实需求，然后一堆人就开始猜了
【 在 amony 的大作中提到: 】
: 是的，几百兆的文件，一条曲线几百万个点，屏幕上没必要画那么多。
: 原型用的matlab，plot不知道有没有处理。
--
修改:z16166 FROM 221.218.161.*
FROM 221.218.161.*
为啥会有滥用的说法？
左手（CRT file io)可以吃饭，右手(os file mapping)也可以吃饭
还有第三只手（os file api)
【 在 xiaoju 的大作中提到: 】
: 怕其他用户同时访问文件的话是个打开权限的问题，这个问题在mswin上还是比较严格的，用trick删除已打开文件甚至被视为安全漏洞。
: 当然我个人也是反对滥用map的，因为很多时候文件并不存放在一个可以高速map的介质上。
:
--
FROM 221.218.161.*
特指linux平台的？win上没听说过有这个问题
【 在 jjfz 的大作中提到: 】
: mmap的sync有时候很慢，特别是大量小文件时
:
--
FROM 221.218.161.*
看来你们脑海里主要是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.*
file mapping在win上使用，从没听到有人诟病说不该（滥）用，pe loader使用，notepad也使用，大量的第三方软件也使用。
楼上有位说linux上map小文件有性能问题，怀疑是下面的文件系统的问题，这不应该是file mapping的锅。
【 在 eGust 的大作中提到: 】
: 都是靠的 cpu 提供的虚拟内存管理支持，直接把文件映射成内存地址，由 page fault 进入内核态，再通过 cpu 把缺少的页面交换到内存中。swap file（win 的 pagefile.sys），pe loader，用的都是相同的技术。
:
--
FROM 221.218.161.*