为何Notepad打开文本文件的速度远低于Large Text File Viewer

核心原因是二者的核心使用场景完全不同，底层加载逻辑做了完全不同的取舍：

• 全量加载 vs 懒加载的本质差异
  Windows自带的Notepad是通用文本编辑器，设计目标是支持全功能编辑，所以打开文件时会把整个文件的所有内容一次性全部读取到内存，同时会做全量的字符编码自动检测、全文档换行符统一转换、整本文本排版预计算、撤销重做缓冲区初始化等一系列操作。尤其旧版Notepad的编码检测逻辑是逐字节扫描整个文件做校验，一旦文件内存在非ASCII字符、换行符格式混乱（同时存在CRLF、LF、CR换行）的情况，就会触发最坏校验逻辑，速度会暴跌，你遇到的6MB文件开25秒大概率就是碰到了这种情况。
  而Large Text File Viewer这类专门的大文本查看工具，核心场景是只读预览超大文本（比如服务器日志、dump导出的文本文件），默认完全不需要支持编辑功能，所以只会加载当前屏幕可视区域的几十KB内容，滚动的时候才动态加载下一段内容，根本不需要把几百MB的文件全部读进内存。
• IO读取方式的效率差异
  Notepad用的是普通的文件IO流读取，需要把数据从磁盘读到内核缓冲区，再拷贝到用户进程的内存空间，全量读取大文件的时候重复拷贝开销极高。
  而Large Text File Viewer普遍采用内存映射文件（Memory Mapped File） 技术，直接把文件的磁盘存储地址映射到进程的虚拟内存空间，省去了内核态到用户态的重复数据拷贝开销，读取大文件的效率比普通IO高至少一个数量级。
• 额外功能的开销差异
  Notepad为了支持全量搜索替换、全选、自动换行适配、字体渲染对齐等编辑功能，打开文件时就要提前计算全文档的所有元数据，这些操作都需要扫描整个文件，进一步拉长了加载时间。
  而专门的大文本查看工具只会在用到对应功能的时候才做部分计算：比如搜索功能默认做分段扫描，自动换行只计算当前可视区域的内容，完全没有额外的前置开销。

举个简单的类比：你要查看一本书的某几页内容，Notepad的逻辑是先把整本书逐字抄写到自己的笔记本上，整理好所有排版之后再给你翻阅；而大文本查看器是直接把原书翻开到你要看的页面，你翻页的时候才给你转到下一页，二者的效率差距自然会非常大。

内容的提问来源于stack exchange，提问作者asmgx