hmmm 打错了，是 2**31(

确实有优化，v8 里叫做小整数，简称 SMI
（不过是有符号的，所以是 -2**32 到 2**32 - 1 的范围）
放数组里效果最明显，在没有 Uint8Array 等一系列数组的时候，就用纯数字数组也能实现很高的执行效率

可以看这里
https://v8.dev/blog/elements-kinds

你这标题和正文有多少语病。。。读了几遍才理解

（其实已经有了，只是使用成本比较高）
DRM 技术就是干这个的。。。

其实可以用 maven 。。。但是，并不是所有的模组都发布到仓库了（

如果不是会员或者是插件的话，就是你被定位到国区了。。。
国区没有投放广告（

（你要是觉得 windows 的这个难以看懂，那 Linux 这边会更让人吃惊，因为起码 windows 还能算准总的内存使用，linux 干脆连总总量都有多种不同口径）
前面说了，主要的问题在于多个进程之间可以有共享内存，这意味着计算的时候，有 3 种可能的思路，分别满足三种特性中的两个，即所谓不可能三角
1. 不算共享的，这就会导致直接相加后少于实际内存使用
2. 算共享的，这就会导致直接相加后多于实际内存使用
3. 算共享的，但是那部分数据除以被共享的次数，可以让加起来的总和等于实际内存使用，但是可能会出现开新进程后，单个进程显示内存使用率反而降低的反常情况
（这 3 种算法就是所谓的 USS RSS PSS ）
可以看出，并不存在一种完美的算法能准确衡量单个进程的内存使用。
而之所以说 Linux 这边更复杂，则是因为 Linux 默认启用了 overcommit 特性，加了个 VSS 指标，申请的内存可以大于实际使用的。这下好了，连找到总内存利用率都变成了不可能的任务。好多人在 Linux 下试图做 fallible allocator，实际根本没用，OOM 基本都是发生在访问内存而不是分配内存的时候。

不用那个样式的话会有很多边界问题要处理。。比如考虑下鼠标移动过快，超过窗口区域
还有用户预期的 aero 效果（指移动到屏幕边界的贴合效果，分屏操作等）这些都是很难在纯粹的 js 层面解决的。。。

建议直接 ida （指它内置的 py

@BeautifulSoap 文本文件也不是存差异的（

@IgniteWhite 据我所知 office 系列的 arm 上都是跑 x86 版本的。。

完全不是这个原因。。。
通过优化布局加速查找那只能算常数优化。。。反正复杂度摆在那里，根本不可能真的有什么决定性的效果。。
占位的原因有很多，唯独不可能是为了优化查询效率，我猜测最有可能的原因有两个，一是空的 id 以前有用，现在不用了，但是为了避免出问题，就没有把后续的都移动一格填满
二是类似传统语言行号一样，预留空间给未来加入新的文本

听起来是当作 360 全景视频了

显然这不是技术问题。
能不能取代，唯一的考虑维度就是它有没有提升效率。
这里的效率不单单是运行效率，显然也包括了开发效率和人力资源利用的效率等等。
如果它没有提升效率，那不用你去提，老板自己会换掉的（除非有利益输送等规格外的东西）。

汽车是不是在断马车的路？
如果真的能断后人的路，那说明它成功了

为啥用 regex ？处理这个你不怕"{"这样的问题吗。。。
显然必须要手动写 parser 做 ast

（ TCP 转发按域名做？？？我觉得一定是哪里理解有偏差

完全服务端渲染，按视频串流到客户端，然后用户侧用 js 记录鼠标键盘事件传输到服务器