- 主题:像ultraedit那种几百兆的文件秒开是怎么做到的？
对于用户态程序，没有特别需求的时候，仍然应该以 fread/fseek/read/lseek 这一套“远古”接口为首选。
用 mmap 并不一定能让你程序变快（用不好还会变慢），而且除非你能 100% 保证你的程序运行时不会有其他进程去修改文件，否则很容易在不可预知的时候 SIGBUS。
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: filemap是现代OS对文件操作的实现方式，是实际的底层操作。fseek是远古时代OS的顺序读取方式，现在是作为兼容层存在的。
: 你可以看看nt源代码，文件，cache，虚拟内存这些玩意底层最后都是一套代码
--
FROM 183.60.88.*
基于行的文本编辑本来就不是随机存取，搞那么底层有毛用？
【 在 marxn (eagle) 的大作中提到: 】
: fseek是C stardard库，不同OS，不同编译器厂商的实现都不一样，用户甚至可以自己去实现standard library。什么时候轮到它去承担底层IO了？
--
FROM 101.98.83.*
是的，几百兆的文件，一条曲线几百万个点，屏幕上没必要画那么多。
原型用的matlab，plot不知道有没有处理。
【 在 zli07 的大作中提到: 】
: 关键不是文件读取，关键是视图层，不能一次性把所有的文字渲染完。
: 至于说读取，如果是64位系统的话，直接mmap进来随便读就行，几G的文本也没问题
:
--
FROM 58.200.129.*
那你这不是个文本编辑器，是个作图工具
所以，很多时候发帖人没有描述清楚自己的真实需求，然后一堆人就开始猜了
【 在 amony 的大作中提到: 】
: 是的，几百兆的文件，一条曲线几百万个点，屏幕上没必要画那么多。
: 原型用的matlab，plot不知道有没有处理。
--
修改:z16166 FROM 221.218.161.*
FROM 221.218.161.*
原帖说了是波形，拖动浏览，局部放大，这些都是针对波形来的。
【 在 z16166 的大作中提到: 】
: 那你这不是个文本编辑器，是个作图工具
: 所以，很多时候发帖人没有描述清楚自己的真实需求，然后一堆人就开始猜了
:
--
FROM 58.200.129.*
记录里带时间戳信息么？
没有的话倒还真不太好办，缺少全局索引
【 在 amony (断网) 的大作中提到: 】
: 原帖说了是波形，拖动浏览，局部放大，这些都是针对波形来的。
--
FROM 114.86.46.*
带，有一列时间
【 在 oldwatch 的大作中提到: 】
: 记录里带时间戳信息么？
: 没有的话倒还真不太好办，缺少全局索引
:
--
FROM 58.200.129.*
怕其他用户同时访问文件的话是个打开权限的问题，这个问题在mswin上还是比较严格的，用trick删除已打开文件甚至被视为安全漏洞。
当然我个人也是反对滥用map的，因为很多时候文件并不存放在一个可以高速map的介质上。
【 在 vonNeumann 的大作中提到: 】
: 对于用户态程序，没有特别需求的时候，仍然应该以 fread/fseek/read/lseek 这一套“远古”接口为首选。
: 用 mmap 并不一定能让你程序变快（用不好还会变慢），而且除非你能 100% 保证你的程序运行时不会有其他进程去修改文件，否则很容易在不可预知的时候 SIGBUS。
:
--
FROM 155.64.23.*
存到内存库数据里
【 在 amony 的大作中提到: 】
: 有个需求，几百兆的csv文件，存的都是波形，
: 想快速打开，然后能够拖动浏览，局部放大之类的。
: 有没有现成的可以用的？
※ 修改:·formydream 于 Apr 14 20:09:23 2021 修改本文·[FROM: 221.235.85.*]
※ 来源:·最水木 客户端·[FROM: 221.235.85.*]
修改:formydream FROM 221.235.85.*
FROM 221.235.85.*
为啥会有滥用的说法？
左手（CRT file io)可以吃饭，右手(os file mapping)也可以吃饭
还有第三只手（os file api)
【 在 xiaoju 的大作中提到: 】
: 怕其他用户同时访问文件的话是个打开权限的问题，这个问题在mswin上还是比较严格的，用trick删除已打开文件甚至被视为安全漏洞。
: 当然我个人也是反对滥用map的，因为很多时候文件并不存放在一个可以高速map的介质上。
:
--
FROM 221.218.161.*