@secondwtq 起码 5 倍差距以上吧，不然 O(n)和 O(2n)都不算一个级别了
底层的东西性能提升几个百分点是很有价值的，但业务层的东西就不是了
至于少到多少用“基本不用”才算准确，你这纯属抠字眼，我不想跟你讨论这个问题

youtube 也出短视频了啊，谷歌该山寨也会去山寨的，你想内容 app 围墙不被我 google 索引，我抄一个产品出来给自家搜索引擎索引就是了

```
const handleClick = useCallback(() => {
setCount(count=>count + 1);
}, [])
```

@R18 要法律严谨的解答这个问题可能需要研究一下钉钉的服务协议

@autoxbc
你 Deno.readFileSync 就已经拿到的是 uint8array 了，切还是全量构造是 Deno.readFileSync 内部的事情，为什么你认为 Deno.readFileSync 一定要给你全量构造的 uint8array
现在作者明显就是想要 Deno.readFileSync 返回切过的 uint8array 这个效果，那肯定说这是个 feature 啊

@kensoz
那我第一要考虑的就是“最小的缺失数”这个需求到底合不合理，最优先考虑是去否掉这个需求

@kensoz
开头的数字不能确定，则无法判断出头部数字的缺失，尾部的数字如果不能确定，则无法判断出尾部数字的缺失

@kensoz 能保证从 1 开始吗？如果不能的话，如果缺的是两边的话是判断不出来的

```
const input = document.createElement("input");
input.type = "file";
input.addEventListener("change", async (event) => {
const arrayBuffer = await input!.files![0].arrayBuffer();
const uint8Array = new Uint8Array(arrayBuffer).subarray(0, 1);
console.log(uint8Array.byteLength);
console.log(uint8Array.buffer.byteLength);
});
document.body.append(input);
```
在 chrome 上试了一下，一个 uint8Array 实例的 byteLength 和它的 buffer.byteLength 不一样是可以达到的，那就没有不合 js 规范的问题，单纯的是 Deno.readFileSync 表现的问题

@AoEiuV020 要 app 主动适配的吧，总不能通过像素判断内容变不变吧

足够信任的朋友&足够令人信服的创业方案

好像是苹果平台 1password 好用，我安卓这边直接通过安卓的密码管理 api 的填写能力，遇到过很多国产 app 用户名填不上去的，而用无障碍的 api 的密码填写就能填上去，1password 用起来就感觉没 lastpass 强

@huang119412
干脆我们假定这个的数组内数字是连续的，这样我们就不需要检查就能知道这个数组是符合条件的了，这样时间复杂度就为 O(0)

你用啥方法也都是 O(n)级别的

@secondwtq 你的观点就属于手里有个锤子。看什么都像钉子想拿锤子来敲

@secondwtq 我用的措辞不是"一样"，而是"一个级别"
也就多线程和 simd 且可以保证用户一定能使用支持新特性的浏览器的场景下 wasm 相比 js 能有超出一个级别性能的可能性，这种场景肯定是占少数，"基本不用"我不认为有什么问题，相比 wasm 多线程和 simd 应优先考虑 webworker 和 gpu.js 这种东西

@secondwtq 当 js 出性能问题的时候，我认为基本不用太去往 wasm 方向考虑，wasm 更多的意义在于能使用其他需要的生态甚至以后出裸 wasm 的 runtime 自成一个生态对标 jvm

@secondwtq 我就算 wasm 能有 js 两倍的效率，对于解决楼主问题也是远远不够的
Fiber 、web worker 、wasm 里，wasm 是离解决楼主问题目标最远的那个