- 主题:像ultraedit那种几百兆的文件秒开是怎么做到的？
都是靠的 cpu 提供的虚拟内存管理支持，直接把文件映射成内存地址，由 page fault 进入内核态，再通过 cpu 把缺少的页面交换到内存中。swap file（win 的 pagefile.sys），pe loader，用的都是相同的技术。
【 在 z16166 (Netguy) 的大作中提到: 】
: 看来你们脑海里主要是linux的mmap，我脑海里的主要是win的file mapping
--
修改:eGust FROM 122.59.26.*
FROM 122.59.26.*
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.*
linux 和 win 对文件的处理差别极大，加上 ntfs 跟 linux 上主流的文件系统也差别极大，具体哪个环节出问题的确是不好说。win 平台文件是内核对象，任何操作都重了许多，关闭之前很多其他操作做不了，既慢又条条框框多，出问题的概率自然就低了。
【 在 z16166 (Netguy) 的大作中提到: 】
: file mapping在win上使用，从没听到有人诟病说不该（滥）用，pe loader使用，notepad也使用，大量的第三方软件也使用。
: 楼上有位说linux上map小文件有性能问题，怀疑是下面的文件系统的问题，这不应该是file mapping的锅。
--
FROM 122.59.26.*
不关闭改名或者删除这个特性，在一致性检查上是个大坑
比如你写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.*
那如果要实现跳转到某一行怎么办？这个不把所有内容都读一次都算不出有多少行吧
【 在 woshidashu 的大作中提到: 】
: 做个假的视图。
:
: 先获取长度，然后根据长度划分成n份，读取第一份，再读取其他n-1份的前多少字节，拖的时候根据比例再去实时读取。
: ....................
- 来自「最水木 for iPhone Xr」
--
FROM 113.104.214.*
我觉得读不是最大的性能瓶颈，瓶颈在显示
【 在 gpmn 的大作中提到: 】
: 内存映射了解一下
:
--
FROM 58.200.129.*