编辑器文档加载占用内存上限的问题

[EyebrowsWhite]

在阅读CodeMirror 源码的时候发现作者对文档的最大长度做了1e9的限制，UTF-16 字符换算一下大概就是两个 G 。

有点好奇为什么设置成 2G ，然后我又查到很多桌面级别的大文件编辑器参考，但是各家也是互不相同，而且很多应该是优化过的，不会把整个文档全加载进内存。

所以有老哥知道为什么的吗？难道是作者一拍脑袋随便定的？

[jifengg]

我觉得如果是写的 “1e9”或类似的 10 进制，可能只是结合经验大概定一下的。
如果是用 8 进制或 16 进制 ,比如 "0xFFFFFFFF"，那有可能是基于字段类型或平台特性定义的。

[EyebrowsWhite]

@jifengg 不过我还是感觉这里用 Magic Number 是不应该的。倒不影响阅读源码，先看吧，可能其他地方会有说明。

[secondwtq]

建议不要只看“源码”。
可以使用 git blame 和 commit message 搜索找到如下几个 commit：
github.com/codemirror/state/commit/76d8735feb5821848fa9af551eb39c0dd0ad60b9 Use 1e9 instead of 2e9 for big integers · codemirror/state@76d8735
github.com/codemirror/view/commit/b5aa501bab1675221553780cd071b93eedb387f2 Use 1e9 instead of 2e9 for big integers · codemirror/view@b5aa501

可见这个数以前是 2e9 。作者给出的理由只有一句话：
> Several engines apparently store only 31 bits in smallints
smallint 可能是指 SQL 里的那个，但是鉴于 CodeMirror 和 SQL 除了一个编辑支持之外就没啥关系，并且“engine”加上“several”和“store”指的应该是一个实现层级的东西而非 SQL 这种接口层级的。那个人猜测应该是指 JS 引擎里的 small integer 优化，这对于实现 Uniform Representation （ https://v2ex.com/t/632869#r_8401400 ）是必要的。
假设一个 32 位的 Uniform Representation ，其中一位用于区分 pointer 类型和 small integer 类型，用于存储 integer 的就只有 31 位，再加一个符号位的话一个 small integer 的绝对值最大就是 2^30 ，差不多就是 1e9 。
楼主给的 StackOverflow 链接中大多数的数字似乎是关于“某个编辑器在特定环境下可以打开某个大小的文件”的，和“某个编辑器理论上可以打开文件大小的最大值”关系甚微。也就一个 EmEditor 的数字“up to a 248 GB limit (or 2.1 billion lines)”算得上一个理论值，这个大概是 EmEditor 用了 signed 32-bit integer 存储行数。

顺便我觉得“开源”只开放“源码”是不完全的。很多信息都隐藏在 VCS history ，issue tracker 和 code review 的过程中。源码只是个成品，它本身很难回答“为什么”的问题。社区驱动的中大型开源项目的源码反而会比较易读，就是因为这些源码之外的信息比较丰富，并且更难出现类似本主题这样的代码质量问题。毕竟这种项目里面，你想改任何的代码，都需要以书面形式说服社区 a) 你为什么要改？ b) 你为什么要这么改？

[EyebrowsWhite]

@secondwtq 感谢指教，你说的很有道理，我一般只会结合着文档和代码一起看，从来没注意过 git 的相关信息，这次学到了