小东西写起来确实舒服，因为从 Web 页面，到后端服务，还有浏览器插件，VSCode 插件，通通都可以 JS 一把梭（不过这只是我的体验，适不适用于楼主可能要看 IDEA+Java 和 VSCode+TS 哪个用起来更顺手 ...）。
外快嘛我觉得没必要，你可以现在开始找个前端合作来搞，如果不能成的话，你学了也没用的 ...

一般来说系统不会自动清除 swap 和 cache 的内存，swap/compressed 页只有在读取的时候才会重新换到 RAM 里（或者被 free 掉了），cache 只有在 RAM 塞满之后才会 evict 。
不是说“有”swap 会加快损耗，是 swap 频繁换入换出会，就一点 swap 然后一直放在那不读跟没有没啥区别（当然你可以较真一开始不是写了几 MB 么 ...）
还有现在 PC 固态一般是主控比颗粒坏得快，但是果子这边 M 系的特色是主控做进 SoC 里了，所以理论上没有这个单点的问题。果子的问题是本身 RAM 起步太少加配又太贵。你换个 16GB RAM 的 PC 一样有 swap 的，现在光看 Mac 内存日经贴还以为 swap 是 M 系果子第一个发明的似的 ...

是不是 systemd 给你默认挂载了
如果可能的话，把 swap 分区彻底删掉试试

@shendaowu 抱歉，我没说清楚，我想要表达的意思是“懂”和“不懂”这个概念是非常主观的。有的人可能认为学过一个编程语言就叫懂编程，有的人认为必须要做过商业项目才算懂编程，有的人认为至少要掌握 OS 和算法等基本功才能谈懂不懂编程，“不懂技术”或者“不懂编程”，不管换什么词，都没个统一的标准。

完全存在一种可能：我期待“懂技术”的人来回复，有一个人认为自己“懂技术”并且回复了，但是我在看了他回复的内容后认为他根本“不懂技术”，他的回复压根不该存在。如果这样的规则实行了的话，他会觉得我很冤枉啊我明明懂啊。问题：他是不是产品的用户？产品要不要考虑他的感受？

本质问题就是人的认知是极其多样的，很多之间是根本没法兼容的。只是互联网把这些人硬拧在了一个地方而已。甚至都不需要互联网，我开始学前端的时候前端正好是高速发展期，我觉得 Web 应用是最牛逼的，底层的东西已经 irrelevant 了，结果这两年我又开始搞底层，我自己不同时候的认知都没法相互兼容。对了，我自认为应该符合大多数“懂编程”的标准，但是其实是压根没有回答你的原问题的资格的，因为我并没有大型应用后端开发的背景。

再举个例子，因为 N 卡的驱动是闭源的，Linux 桌面社区一直有那么一小撮人，每次讨论显卡问题时都要出来刷存在感，说不要买 N 卡，f*** NVIDIA 之类的。我是觉得他们有点极端了，但是又觉得有些道理，并且有一种如果这种人多一点能微小地推进一下开源的想法。有句话叫 One man's terrorist is another man's freedom fighter ，楼主看上去也是有这个共情能力的。

楼主可能觉得所有“机制”的存在都是合理的所以才想要“解释”。我觉得没有完美的机制，所有的机制只要存在都必然要让一部分人不满意。单纯的“解释”作用有限，比如这个 App 升级带来的“负优化”问题 https://v2ex.com/t/960945#r_13423807 ，这个楼主看上去就想要“解释”，我站在用户的角度，认为楼主的“解释”只是让我涨了姿势，但是不能消除我的不满。根本上还是要解决“负优化”这个问题本身。

这里根本的矛盾是用户感知到“新的更新出现了 regression”。只是用户不会这么描述问题，也不知道“用户体验变差对淘宝没有收益，所以这只是懒得优化”。所以就用“负优化”这个词来指代这种现象。

在用户的认知里，新的版本应该在最终体验上“应该”是“正优化”的。那么现状是开发新版本肯定有一定的工作量，就连用户更新都要耗费网络流量、存储空间和 CPU 时间，最后唯一的感知是 regression ，那么你们这些工作量干啥去了呢，当然是做了“负优化”。
你会说我做了新功能啊。可是根据二八定律，大多数新功能用户感知不到。安全更新更是如此。

争论“负优化”这个说法的具体含义，意义有限，这个词只是一个缩写罢了。你可以给用户灌输“用户体验变差对淘宝没有收益，所以这只是懒得优化”，但是你没有解决用户感知到的问题，只会起“试图教育用户”的“负效果”罢了。

怎么定义“懂技术的”和“不懂技术的”？是不是只有说你爱听的话才是“懂技术的”？

一个典型的例子是 Haskell 的 GHC 编译器，这货（所编译出的程序）在版本 8 之后就是开局分配 1TB 的虚拟内存空间。这是对应的 tracker：gitlab.haskell.org/ghc/ghc/-/issues/9706 #9706: New block-structured heap organization for 64-bit · Issues · Glasgow Haskell Compiler / GHC · GitLab
根据这个 issue 的描述，在之前，GHC 的 allocator 会首先向 OS 申请叫做 megablock 的较大块内存，然后再分成叫做 block 的较小块内存，之后在 block 中处理具体的分配请求。而现在不需要 megablock 这个概念了（或者说只有一个全局的 1TB megablock ），大大简化了实现。

这么做最明显的好处之一是，由于 GHC 使用 tracing GC ，在 GC 时需要检查一个指针是否指向堆中的数据（ gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-alloced heap alloced · Wiki · Glasgow Haskell Compiler / GHC · GitLab ），因为可能有许多个 megablock ，这个检查在之前是非常麻烦的——他们实现了一套 cache 机制，我觉得很像软件层的 TLB ，先用 tag 去找，找不到再去到表里面搜。而现在只有一个 megablock ，只需要一个全局变量记录它的地址，直接检查是不是在它的 1TB 范围内就可以了（这个应该还可以继续优化，因为理论上你可以向 OS 提出特定的对齐要求，这样直接一个 bitwise-and 搞定）。实现者声称在一些 benchmark 上获得了 8%+ 的提升。注意这个不是靠减少 syscall 得到的。
当然，由于没有了 megablock 的概念，malloc 和 free 的过程也被简化了。

当然，这个 trick 首先需要地址空间足够大，所以只能在 64 位环境下使用。
另外在 Windows 上的实现有些不同，因为 Windows 的 memory overcommitment 似乎和 Linux 上不太一样。

之所以要提 Windows 不只是因为原 issue 上重点关照了这方面，还是因为之前我关注到网络上的一些言论，说最好不要彻底关闭 Windows 的 pagefile ，会导致很多软件出问题，甚至包括 MSFT 官方的一些软件。我一直都很好奇，按理说有没有 pagefile/swap 并不是软件应该关心的问题，如果我 8GB DRAM+8GB pagefile 能正常工作，16GB DRAM 不带 pagefile 不应该更差。看到这个问题就觉得可能跟这个有关系。我的推测是 Windows 下的很多程序可能比较喜欢以当前系统的 DRAM 大小为系数来预分配内存，这样所有程序想要分配的内存总大小很容易超过 DRAM 大小，就必须要 pagefile 来兜个底。但是网上的建议是你哪怕开几 MB 的 pagefile 创建一下全国文明系统都不要彻底关掉，如果真的只有几 MB 的话就没啥作用了。不过 Windows 默认的 pagefile 设置是“系统自动管理”，不够的时候会自动扩容（虽然最多只能 3x DRAM 大小），并且 NTFS 还支持 Sparse file 。另一个因素是现在 Windows 主流软件几乎全员或多或少都要 GPU 加速，而 DRAM 和 VRAM 之间的数据传输也需要 memory map 。还有一个则是根据官方文档，Windows 的 CreateFileMappingW(INVALID_HANDLE_VALUE, ... （类似 MAP_ANON ）是"backed by the system paging file"，而在 Linux/BSD 上直接出来就是 anonymous page ，但是 Raymond Chen 澄清过（ bytepointer.com/resources/old_new_thing/20130301_058_the_source_of_much_confusion_backed_by_the_system_paging_file.htm The source of much confusion: "backed by the system paging file" ）这个有很多误会，"backed"是指"page out 的时候会扔到 pagefile 去"，这样得到的内存空间其实和 Heap­Allocate/Virtual­Alloc() 是一样的，也就是说基本是一句废话。目前我没有时间或者没有方法来验证这些猜测，所以这个问题到现在还没搞明白，不知道 V 友有没有清楚具体原因的。

Windows 下还有更加生草的问题——和楼上所关心的“操作系统付出的代价”密切相关。由于 GHC 采用了这种新的内存管理模式，在老版 WSL 上会莫名奇妙地慢到不可用：github.com/microsoft/WSL/issues/1671 `stack ghc` painfully slow · Issue #1671 · microsoft/WSL · GitHub 这个问题后来貌似被修复了，不过可见虚拟内存大小并非在所有情况下都无所谓。上面有人说开发板也可以跑，前提也是开发板的软件是比较成熟的。

此外 Google 的 Go 实现在某些版本似乎也有类似的机制。至于 Chrome 这个事情，https://unix.stackexchange.com/a/741548 Why Google Chrome is reserving Terabytes scale virtual memory? 这个回答指出这和 V8 引擎在近年实现的一个新的安全功能有关。V8 中的一些 bug 可能允许攻击者利用 V8 内部代码实现内存读写，因此这个新的机制会预先分配 1TB 的虚拟地址空间，并将 JS 程序的数据全都分配在这里面，地址则使用 40-bit 数存储。这样就把类似攻击的影响面限制在了这 1TB 范围之内。

最后必须批评类似话题常见的一种风气——对你没有影响就不用管，这属于问了 Y ，然后回答者自作主张去回答 X 。典型是这个帖子：reddit.com/r/linuxquestions/comments/w4im5m/chrome_using_11_terabytes_of_virtual_memory 这里很明显这个 sub 的平均技术水平一般——不清楚虚拟地址空间概念的比比皆是，不过鉴于本身就是 /r/linuxquestions 倒也没啥奇怪的。但是就算虚拟地址空间占用对用户没有什么意义，为什么别的进程都很正常，就你 Chrome 搞特殊呢？这本身就是个很有趣的问题。

西方的社交网络也在开倒车，看看 Twitter 和 Reddit ...
还是多多关注联邦式平台之类的吧

> 因为网上总有很多喷子杠精，去翻你的历史，一字一句的分析，然后跑来莫名其妙的攻击你，很烦
你会发现匿名了也会有“人”说你这么牛逼为啥匿名 :)

建议不要只看“源码”。
可以使用 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) 你为什么要这么改？

这个主题颇有 The Old New Thing 的观感

新的 Teams joke ...

感受：楼主的描述与我的刻板印象相冲突

一般来说，前端才是喜欢折腾“雅”的，后端就喜欢硬糊

首先目前 Gamedev “开源”的实践典型是，引擎代码 GPL ，美术音乐素材专有。IMNAL ，不过我觉得有个问题是 GPL 要求发布的东西是“all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work”，它关心的一直在 executable 层次，也就是说它明确保证的只有：你能 build 出 executable ，你能修改代码之后再 build 出（改过的） executable 。GPL 原文并没有定义什么是“executable”，而从技术层面理解的话这个词对不同场合的 applicability 是有区别的，比如天然最适合 C/C++ 等编译型语言。

从 executable 到一个完整的游戏（产品）中间是有很大的空间的，这中间包括但不限于素材，本地化文本，关卡地图，脚本等。很多简单的 mod 就是改个素材或者改个数值，从软件开发的角度理解，这些属于“配置”或者“输入数据”的范围，我 GPL 了我的网站前后端源码，但是几乎没人 GPL 数据库里的用户数据。这个是可以理解的。

但是作为程序员都知道，“代码”和“数据”并没有明确的分界线，所以这里我觉得是个灰色地带。就算配置不具备图灵完全的能力，一些比较复杂的配置也能“模拟”简单程序的效果，我该不该开源我的“配置”？

以上是主要从游戏的角度出发来分析，因为游戏里面，除引擎核心之外的东西实在是数量巨大种类繁多，因此我觉得这个问题是比较复杂的。传统的软件产品反倒是比较单纯，我比较了解的一个是 Blender ，Blender 本身是 GPL 的，而因为它是个用户群很大的 DCC ，它的第三方二次开发社区也很活跃。其中有一个做插件商店的网站 BlenderMarket ，算是圈内有一定影响力的。在该网站上发布内容需要选择 license ，网站只提供有限的选项：support.blendermarket.com/article/54-available-licensing-options 其中对“asset”类和“code”类是分开处理的，“code”类只允许选择 GPL 或 MIT license 。能用 MIT 应该是因为 MIT 是 GPL-compatible 的（可以直接 relicense 成 GPL ），但是具体的原因网站也并没有给出解释，我觉得区别大概在于用 MIT 的话，其他和 Blender 无关的非 FOSS 项目也可以引用其中的代码。（最神奇的是这些东西虽然法律上是开源的但是还是很多人去付费）
类似的项目还有很多比如 WordPress ，不过这些项目的具体情况我就不怎么了解了。
（现在又出现了新的风暴了：AI 模型的权重、数据集等 ...）

另外就是建议不要仅仅停留在 x86 上，可以看看 ARM 之类的，现在资源也丰富起来了，以及一些资料较少，但是也很有意思的较新的架构比如 RISC-V ，甚至是已经淡出主流的架构比如 Alpha ，很多设计上的选择很有启发性（也包括传统 CPU 和其他处理器比如 GPU 的架构设计也有很有趣的区别）

学习任何东西最好的办法是实践，就好像学英语要坚持有效的输入输出
当然怎么实践有学问，比如学 C#，可以先拿 C# 刷几道 LeetCode 熟悉基本用法，写几个小工具之类的，但是到后面取决于你要做什么，搞 Web 服务，做 Windows 程序开发，做游戏等涉及到的库和知识体系是有很大不同的
汇编也一样，如果你是想操作硬件那就试着写个 bootloader ，研究开源 OS 中一些 Arch-specific 的设计和实现，做安全就去解 crackme
我一开始学汇编是想着搞点逆向，后来是研究编程语言语义的实现，再后来是做程序优化，结果都搞了个半吊子，现在 jl je jnz 都分不清楚，但是干活勉强够用

@secondwtq 贴错了，倒数第二个 URL 是这个： https://www.v2ex.com/t/845257

硬件实现整数除法具体的算法我不清楚，但是网上大致也可以查到，比如这个
stackoverflow.com/questions/71420116/why-is-there-only-little-difference-in-integer-division-throughput-with-larger-v performance - Why is there only little difference in integer division throughput with larger values on AMD Zen? - Stack Overflow
但是总的来说整数除法比乘法的算法要复杂得多，并且似乎只能一点点算，所以不同长度有可能有可见的区别，并且一般较老的硬件问题更严重：
https://uops.info/table.html?search=idiv%20r&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SKL=on&cb_ADLP=on&cb_ADLE=on&cb_ZEN2=on&cb_ZEN3=on&cb_measurements=on&cb_doc=on&cb_base=on
另一个相关的问题是浮点 SIMD 除法，部分硬件上性能也可能和向量长度相关（很少有架构提供 SIMD 整除指令，一般都是用软件实现）：
https://uops.info/table.html?search=vdivp&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SKL=on&cb_ADLP=on&cb_ADLE=on&cb_ZEN2=on&cb_ZEN3=on&cb_ZEN4=on&cb_measurements=on&cb_doc=on&cb_base=on&cb_avx=on&cb_avx2=on&cb_avx512=on

一个特例是除数为整数的整数除法，编译器会做优化，避免使用硬件除法器：
https://v2ex.com/t/933790#r_12971302
如果楼主的程序是这种情况一般性能会更好。不过我没有研究过这个在不同长度下的性能表现，楼主可以写个小 case 扔进 uiCA/llvm-mca 里面试试

当然最吼的还是都 profile 试试，这个除法操作是不是瓶颈：
https://v2ex.com/t/933790 https://v2ex.com/t/828141

大概是学校自己编的 C 语言教材，花了一周看了一遍从不怎么会编程到勉强会编程
再也没有单独的一本书能做到如此大幅度的提高了 ...

那段时间还把酷壳所有能勉强看个热闹的文章刷了一遍
R.I.P.