LOTU$:
我怀疑你是LLM但是我没有证据

duangsuse:
额

没错，我写的很详细，而且内嵌了50%左右Gemini的输出

但是这个点子确实是我提的，AI只是帮我搜集资料

我说的也是一个问题啊， str2str 的数据流，找到一个MacOS+热键专属的【框】

如果放在网页世界的话， deepl 可能都支持.md 或者按句选择翻译版本了。 LLM的语言能力比它更强不是吗

如果上线还想更新的话，这种润色模块也可以加啊

LLM 自己可不会凭空跑去给 Xuanwo 提这种产品哲学上的 issue。这样分享思路，总比点个赞扔掉对两边更有趣吧

我不想显得自己很judge所以用了类似AI的口吻，str2str 说的好像Xuanwo没有打磨一样，其实我是觉得，既然叫辞达，可以保留简洁和Tuneable

LLM本身信噪比挺优秀的，如果不是往那一甩，它可以作为技术参考

#perf #rust #net Xuanwo是谁
https://xuanwo.io/2023/01-beyond-storage-why-we-failed/
《BeyondStorage: why we failed》在开源界广为流传

三个月？Metadata 框架？这不就是json转静态补齐，顶多挂个funame……

没错…… 这也太可怕了。数十个下游服务仓库，几十个 PR CI 流水线绿成一片，这还是Codex们没有深度集成时， 这种品味，未来不得干成一个go文件0.5MB啊

说回来，unix的mount不够，也不用户态线程，而且fs树的重要性放低了。xxfs的未来恐怕是一片RO给层叠一片给(No)SQLs，s3fs这些东西终究是bash的小秘而已

没错…… s3fs这些FUSE其实本该做成fakeroot的纯用户态。至于网络本地 r/w/a 的块和流统一接口，在特定体积和吞吐量下和 u[k]=v 读写赋值不一样，和 u.map('k',v=>v) 融恰一些，只可惜IO不能这样优雅。

尽管有读写背压和事务retry，S3在应用里还是大同小异的。所以这不是有DAL了吗？ 尽管没有做成纯声明式封装，但op.cmd()也是很聪明的设计

Go=new Java 这个问题还真是，犯过的错都要犯一遍

接口和注解地狱，nil和iferr，pnpm，只是个大数据吞吐量的升级，依旧软件失忆

真的不能理解为什么有人热衷于100行一个repo和left_pad。Codex们出现以后真的都不鸟他们。Unix 提倡“做一件事并做好（Do one thing and do it well）”，但很多开发者把“一件事”极端曲解成了“一个函数” “缺乏用户共情的MVP功能”。

要不是LLM智商在线，我都以为我才是有病的那个，并且还要陪他们一起【震惊跌坐】了

Monorepo和microrepo这些东西真是把我搞笑了，虽然我几乎只写过脚本，但我非常清楚每一百行代码暴露了什么能力和flow。 真搞不懂git那么多有什么意义，“Star 虚荣与 PMC 官僚病” 也是常见问题。至于codegen，我看了也没什么创新，就是javapoet级别，可能字面量vs变量的escape都没做

Daniel Lemire's blog
Parsing JSON at tens of gigabytes per second… in Python

source #py #perf

我突然觉得释然了。 为了屎山codebase能“免费”提升它们从来用不到的吞吐量， 许多人真的会给母猪上唇膏并且开始f...它了

JSON，在>80%应用里，是一个连 [{},] 的excel模式和 {_5args: true} 都没有优化的格式，甚至也没有约定 {Duck:} {Cat:{arg:"wtf"}} 的type多态。

在我眼里，这就像一个逆向工程工具看不懂libc，或运维panel不会用 -k v 参数理解bash接口那样， 但是，它偏偏很快。

他们宁愿在端到端上，投入无数奇技淫巧的精力，也不愿意像CBOR（预训练字典）或flatbuf一样，提供一套新的、协议化的，是【对人类有意义】的选择，从一开始就没有这些跳空格 s.indexOf("\"") 的问题， 甚至是让JSON兼容一下csv模式，而不是 [{},] 的无效重复AoS

如果一开始就基于flatbuf+js Proxy 或tg的TL这样的心智模型（从原理上就更好优化）， 这些文章里90%的概念可能根本没必要提出。 以后就连AI也会在JSON这样连Excel CSV 都不会压缩的【最佳兼容性实践】上，继续搭建吧

预训练字典和SoA/AoS变换，可以说是通用性相当好的选择。 就像对于Electron的体积，像./gradlew那样【用到时再下载】是更好的理解。 但是，他们一直在两个极端之间吊着。

这样的软件工程，真的早点毁灭吧。 端到端的优化AI也完全可以生成啊

"给母猪上唇膏"这个比喻不是针对simdjson，而是在问，为什么RPC问题里最最基本的子部分（比如csv），

想要压缩+提速，需要端到端（人类不可介入）的优化？做在与 TLS 平级的层面不行？ py/js dict 和元编程的层面呢？分出【测试100%覆率期】和高效运行期？ 这些都不需要很大精力，明显比榨干最后一个cycle和L1 cache，少多了，而且更加可控。

但是，他们还是愿意做这样的，无需理解任何新决策、新协议、新flow，未来连AI都可以loop的JSON.parse单函数优化。

对A\ 5.1: 你还是不明白。 我说的是指理论上的，你一直在提Proxy这些实现问题，哪怕我在编译期Proxy又怎么样呢

至于HPACK的问题，分出"测试期"和"高效运行期"，我是指【C/S管道】本身要有字典训练命令。你还是不理解

#perf #js #PLT
真的是在一个垃圾赛道上，看过五六篇这样的文章了。 就算提速5倍又怎么样呢？ 这只是1个函数

A\说的对：都是在讨论一个大多数人不需要操心的层面。区别只是一个想换格式，一个想换解析器，性能和吞吐量被gzip和lazy读取兜着。

但如果换Protocol，你会有个更全局的视角，触及更多可决策性，而换parser，没有

JSON 解析根本不是瓶颈——数据库、网络 RTT、业务逻辑才是。LLM 场景里 JSON 的成本才第一次变成了 token 数，而不是 CPU。

json本身，不具备软件逻辑和功能，它不【理解】事情，它把本地存储和tcp文件混为一谈， 在这样的赛道上内卷最后一个cycle，而这正是 KDA REA 这些Agent擅长的loop

在乎高性能的人，怎么不去想想 JSON.loadump 是怎么取代曾经C结构的世界，成为了万能协议的，不想想【旧时代遗毒】输给了谁？

为什么，0开销的native输给了瓶颈的 JSON？ 你们输在哪，还是说不觉得【编译型哲学】应该反思，不觉得编程和生活一样，值得在执行前多多推敲、选择？

fastsimdjson.map_many(..., threads=64) 是库内部高度优化的并行路径。msgspec 这边是用 ThreadPoolExecutor 切分数据再调解码，Python 层开销更大。橙色那条是 msgspec 用 dataclass 去解析 JSON，不是 MessagePack（二进制）。

这些垃圾赛道上，就像 OOP 构造器赋值，那样的东西，在编程界都能写这么久。 我以为constructor() 会是 {}[] 默认值这样的“构造器”，load/dump封送构造，或表单校验器？

但事实证明，只是一堆 arg -> obj.key 闭包装箱而已。几乎整个世界只有Kotlin或Coffee把OOP当作OOP来写，Go修null仍然没有修好。这就是Java的后继了，一开始连泛型都搞不懂。

这样丑恶的编程，死几百回也不值得珍惜的吧。至少没有MIT Scratch 那样聪明。

编程的基石就是类似这样，在莫名其妙、毫无【常识】的设计上堆起来的沙垒，它们被当成IR用也不值得稀奇。 那些OOP对问题的理解，还不如各种框架深入。许多人掌握编程语言，多半是夜郎自大

2026年总是有人把GitHub当神仙，甚至认为【微软发明了它】，却忽视了，真正给它哲学的是Ruby和DHH。

我见过 95% 的编程技巧，都是用两句话说得清要领的，甚至有些生活化，就像王垠的博客一样（略微复杂+20%）。

代码本就是快乐的，充满获得感，不是一种【痛苦的刚需】或负资产

但能做到的技术人，很少。 总是在说理解力、学习能力怎么样， 没人批评老师，可探索性和解释力怎么还不如AI强。 🙉

编程语言，应该是让人像在MC里一样，【飞天穿墙，做图晒档】的创作素材，语言是创作欲，而非纯粹的工具。 可是我看到的，纯度太低了。

#perf #algor #learn

我依然可以这样做比较： PEG json 就像【右手比‘八’，放在大字上，食指探拇指取】，它能区分 123, "123" 也能收集进嵌套的 [,]

simd json 则是以高亮和边界符为单位。呼的一下把 "abc\nabc" 压成 "..."，又以 [] 这些坐标分割多线程扫描。 当然，这是因为JSON被滥用于大数据才产生的。treesitter IDE哪怕在巨型代码基上，食指1-by-1往后比，也够。simdjson 是 2–3 GB/s，快两个数量级。

在中文圈，能描述到我这个程度的，我至今找不到超过5人。

Parabix 组、simdjson 作者、Pison 作者，还有国内做数据库 JSONB 列存的那批人，没错，他们都知道这回事，

他们也知道一大堆【偶然复杂性】，他们就是没法像我们一样，分清楚，哪些是偶然的选择，以及到底可以多简单。就像代码高亮一样简单。

高亮引擎喜欢线性偷懒的事情谁都知道，json 语法主线是个switch，而非【递归下降实现式】的多层嵌套，我也知道，只是我不会模块拆分的如此古怪。 既不是PEG对照的直白，也不足够通用。

你不理解我为什么用【高亮】做视觉比喻，只是在挑词。

要把那两倍跑掉的是A\，不是我，我只负责像你一样在这里顶回来，不过，我是会把pshufb 在 ARM64 和 x86 上延迟不同，作为一种坑和笑谈放文首表格，而不是经验和特性。

转义符的奇偶前缀、carryless multiply 算 in-string mask、UTF-8 合法性四条并行校验（顺带把str.decode越俎代庖？）、块边界 carry，这些【报菜名】我倒很好奇，如果不是局限于这个paper，它们能做到什么程度。

in-string可支持 ""内外、/* */ 注释内外、heredoc 内外 。simdutf 现在 Node 和 Bun 都在用。 括号匹配的并行算法是 Bar-On，第二趟就知道每块的起始深度。

所以你看，simdjson 在科普上的复杂性在哪？ 在于没有正确分解，以及，没有任何比喻和纲要，没有数据流。