@Nazz rwmutex 的 scale 能力一直有问题，比如最近我看到的这个 issue https://github.com/cockroachdb/cockroach/issues/109443

@infinityv 全局 rwmutex 估计只会被秒杀

@Nazz 应该是一直在优化

专用分词器是指带词库的那种？短文本 title 很适合 ngram ，长文本由于各类干扰词很多而且为了缩减总 token 量才需要词库

@NoOneNoBody 我也不是作者

结构固定直接走代码生成不就行了

@hkhk366 按照官方说明索引 100 万文件要花 1 分钟： https://www.voidtools.com/en-us/faq/#how_long_will_it_take_to_index_my_files. 考虑到要建索引和分词 1 秒 100 万不太可能。倒排索引我觉得 1gram 和 2gram 就行。文件名 1 个索引，文件大小 1 个索引。文件名索引存[]string ，其他索引直接存[]bytes 方便 bitwise 操作。比如搜"abcd", 那就 ("ab"索引 AND "bc"索引 AND "cd"索引) 。然后再 AND 文件大小索引。最后反查一遍文件名数组把 bitwise 结果为 1 的找出来。对于 regex 的情况如果包含常固定字符可以先用 ngram 过滤一遍，剩余结果再真用 regex 匹配

没明白 abc.txt 难分词的原因，搜索 a 那所有包含 a 的文件都应该显示。另外"倒排 100 万文件大约需要 1 个 GB 的空间"感觉也不对，你是用 sqlite 的全文检索测试的吗

看上去 google cloud function 可以无限扩展 https://cloud.google.com/functions/docs/configuring/max-instances?hl=zh-cn

缓存策略相关的论文很多，包括各种改进版的 lru 策略也很多

@Nazz Hierarchical Timing Wheels, 我是照着 caffeine 的 java 代码翻译的，也可以 google 。LFU 就复杂些了, 建议去看 W-TinyLFU 的论文。简单来说 frequency 数据是存在 Count-Min Sketch 这种概率类数据结构里的，所以占用空间很小

@Nazz 知识盲区，也许这个能参考一下: https://github.com/golang/go/issues/54766

我以前在的时候得物有工时排行榜的，而且还是公开的。你早下班会拉低整个组的平均工时

@Nazz 好家伙，这个展开出乎我意料。可能这是 V2EX 为数不多的外国朋友

这个看上去可能行 https://civitai.com/models/125264/golang-gopher

@neochen13 你是如何找到我这个 29 天前的主题的。看 issue Insomnia 8.3 应该已经恢复离线了

我测了测纯 GET 确实很快，因为用的是 xsync map( https://github.com/puzpuzpuz/xsync). 不过按照 xsync 作者的说法 GC 压力会更高( https://github.com/puzpuzpuz/xsync/issues/94)，这点从 benchmark 的 allocs 上倒是不太能看出来

无意中看到了另一个快 5 倍的 https://github.com/maypok86/otter (看 bench 写入比我的 Theine 也快 5 倍), 可以研究一下

直连数据库执行 sql 也要 10s 吗？最好把 query plan 也发出来