BinaryTree

Software Engineer at Uber building mobile ML/AI platform.
Ex: Tesla
Ex: Googler

Personally building Dota2 Coaching Agent called phylactery.

[BinaryTree @BtreeWw]

@tison1096 掉进兔子洞和上次听到的别人不穿你的鞋有异曲同工之妙啊 😏

[BinaryTree @BtreeWw]

希望所有还在为文件读取性能辩解的人看看云风大佬的原话。
初衷是一个人可读的持久化方案。这一点对微信可能有好有坏，但是我个人不持反对意见。至少对用户来说这是好设计。
然而我反对的是微信的存储问题和人可读带来的抗腐败几乎毫不相关。这并不是一个解决微信占用手机几十G空间的解决方案。

[云风 @cloudwu]

@disksing plain text 对 db 的优势不在于性能，前面想说的是 plain text 没有性能劣势。但应对软件腐烂导致的数据损坏方面有巨大的优势。即使微信不维护了，一个人可读的 plain text 中的数据也可以继续使用。

[BinaryTree @BtreeWw]

@quakewang 实际就是这么按你说的这么做的，模型runtime甚至不接受byte[]。
然而app很多时候就是牵一发而动全身。

[BinaryTree @BtreeWw]

举个实际例子为什么说跨领域的开发者不能共情。
我们Mobile ML platform的ML model实际属于公司资产，但是没办法只能在用户的手机上跑。
所以在加密和性能中有一个取舍，也就是所谓的Trade off。
Model加密就不能用mmap，就需要直接把整个解密后的文件读到内存，或者临时生成一个解密的本地文件来进行mmap。仅仅这一个改动就在灰度测试的时候造成了大量的OOM提高，而我们的Model大多数都在10MB以下。
这也是为什么我说接近100MB的文件读进内存在app的场景就是个天文数字。更不要提这个文件需要加密。

[BinaryTree @BtreeWw]

@quakewang 10mb肯定不会直接导致oom。但是10mb的额外内存压力就会直接导致OOM的几率提高。这个几率放到了我们公司的scale上那就是很多。

[BinaryTree @BtreeWw]

@geniusvczh 有点拔高qq了，手q做的一样烂，还有之前往app里塞unreal这种烂活。而且其实没人为微信辩护说他做得好，只是云飞给出的方案和微信现在的问题几乎没啥关系。

[BinaryTree @BtreeWw]

@tapopat @middlefeng 就是这个原因啊，微信在用户手机肆无忌惮拉屎槽点太多了，但是这和sqlite还是plain text没有任何关系。

[BinaryTree @BtreeWw]

@Piglei 所以我选择做dota2 agent 😎

[BinaryTree @BtreeWw]

@geniusvczh 你这个回复更进一步说明不能互相共情。

[BinaryTree @BtreeWw]

@RaeAlisa_ None of them can beat Jira.

[BinaryTree @BtreeWw]

@chiulabs @jeffdylan535 @williamlong 哪种技术都不能。因为根本是两个不同的东西，这也是原文最不好的一点，微信动辄占用几十G空间和Sqlite可以说是毫无任何关系。

[BinaryTree @BtreeWw]

@pcb_77 @cloudwu 比如你在微信里，搜你之前发过的一条信息，然后从那条结果里点进去，再读取这条之前的前后50条数据在支持上下滑动分页。

[BinaryTree @BtreeWw]

@Arthur2e5 难道vibe coding不是实现大神随口说的“架构”的最好方式？

[BinaryTree @BtreeWw]

作为一个既不懂存储，又不懂数据库的Android工程师。今天非常较真的用Claude Code做了一个简单的benchmark。
TL;DR : 在绝大多数微信的使用场景下，File Grep都没什么优势，而且劣势很大。
用的机器是Pixel 10 Pro，云风所谓的“一整年数据”，120 万条消息 / 3000 万字。文件方案 vs 微信的 WCDB。
用文件纯写入确实很快，300k的条/s，数据库大概是43k条/s。
存储方面一年的消息单文件大概是86.5mb对比数据库用了162mb。
但是查询方面差距就太大了，数据库往上翻历史大概都是在1ms以内，而文件需要大概500ms的p50。这在什么app里都是一个不可接受的延迟。
而且这个所以为的“高效grep”在查询场景搜索也需要170ms,而数据库只需要0.5ms。
具体的AI报告我放在了Gist里面https://t.co/RyQkbo29FT
源代码就不发了，好奇的可以用评论区的prompt来复现：

[云风 @cloudwu]

@passluo 微信的开发人员根本就不懂该怎么储存数据。这种聊天软件，文本和媒体文件分开存，文本根本就不应该保存在什么数据库(sqlite)里, 一个对话一个文本文件追加就可以了。需要搜索的时候 grep 一下性能完全符合需求。一个对话能有多少文本？一秒一个字 24 小时不间断，一年也就 30M 个字。

[BinaryTree @BtreeWw]

@timtimtim_eth 🥲 我反而觉得卸载X可能减轻痛苦。

[BinaryTree @BtreeWw]

@yetone 还在论战500ms，反手A\已经发布Sonnet 5来抢热度了。🤬

[BinaryTree @BtreeWw]

@birdhk3 @cloudwu 每个点肯定都很多优化空间的。但是这并没有证明用append only file就是对的。

[BinaryTree @BtreeWw]

@liustack @levelsio 所以跨领域就是很难共情。
Sqlite在android有多难用估计十年前写过android的SWE都有体会。所以没人真的觉得他是唯一最优解。
本地存数据和后端存数据考虑的点也很不一样。这也是为什么android需要那么多存储数据的方式。就连微信自己也有MMKV和WCDB两种。

[BinaryTree @BtreeWw]

@PandaTalk8 也不用AI时代了啊，Stormzhang几年前就赚的盆满钵满了。

[BinaryTree @BtreeWw]

@acfortwi888888 @vanillaCitron 其实我很好奇为什么X上这么多人，大家都是AI Native。随手试一试搞出一个更好的方案多好。
我对一个跨领域的人，随口说业界头部公司＂全是一群不懂的人＂说出的话也是天然的有警惕。
今天趁这个benchmark确实也学到很多东西，也算有收获。

[BinaryTree @BtreeWw]

@yfractal 不同领域的开发确实无法共情。就跟LLM一样。我们都拥有不一样的context。一样的user prompt必然有完全不一样的结果。