Deepin 20 ，打开时报错说 libstdc++.so.6 版本太低诶。。

```
/usr/share/reqable/reqable: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/share/reqable/lib/libdesktop_multi_window_plugin.so)
/usr/share/reqable/reqable: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/share/reqable/lib/libreqable_appdump_plugin.so)
```

```js
s = 'txt=123,txt=kg66vv,hhj,txt=6966,ggg'
s.match(/(?<=(?:^|,)[^=]+=)([^,]*6[^,]*)(?=,|$)/g)
```

@luozic #6 感觉 DuckDB 读文件时，性能有点问题？


感觉 DuckDB 读空缓冲区后，Writer 才能继续写。写满后，DuckDB 才去读一样？

同样的内容，会因喂给 DuckDB 的姿势不同，表现出不同的速度差异。。

就像 Python 的假多线程一样，只能有一个线程活跃。。

https://i.imgur.com/zDWIvwg.png

@ComplexPug #14 我用 Lua 写了个（可限制内存）词频统计，并和 DuckDB 比了下速度，感觉还行。


1. 测试数据

[知乎回答]( https://www.zhihu.com/answer/1906560411 ) 里，分享的《英文维基百科（仅文本版）》，并简单用脚本预处理了下（去标点、每词一行、转小写）。

解压后：13.33 GB
处理后：12.84 GB ，23 亿词（不重复的有 854W ）


2. 测试结果

- ＤｕｃｋＤＢ　（不限制内存）：4 分半（ 1.0X ）
- Ｌｕａ（最多存１００Ｍ文本）：7 分半（ 1.6X ），01 个共 103MB 临时文件
- Ｌｕａ（最多存　１０Ｍ文本）：8 分钟（ 1.7X ），23 个共 306MB 临时文件


3. 测试硬件：i5-8250U 低压 CPU 轻薄本。。


4. 运行截图

https://i.imgur.com/Th6QoLr.png


5. 预处理脚本

```shell
unzip -p enwiki_text.zip | tr -cs "[:alnum:]'-" '\n' | tr [:upper:] [:lower:]
```


6. Lua 脚本（ V 站吞空格，所以将行首缩进，都转为全角空格了）

```lua
#!luajit
local TOP_NUM = 1000
local MAX_SIZE = tonumber(arg[1] or 16) * 2 ^ 20

local dict = {}
local dict_size = 0
local files = {}
local words = {}
local word = ''
local freq = 0

function heap_swap(heap, comp, lhs, rhs, func, next)
　 if comp(heap[lhs], heap[rhs]) then
　　 heap[lhs], heap[rhs] = heap[rhs], heap[lhs]
　　 func(heap, comp, next)
　 end
end

function heap_up(heap, comp, idx)
　 if idx > 1 then
　　 local pa = math.floor(idx / 2)
　　 heap_swap(heap, comp, idx, pa, heap_up, pa)
　 end
end

function heap_down(heap, comp, idx)
　 if idx <= #heap / 2 then
　　 local left, right = idx * 2, idx * 2 + 1
　　 local son = right > #heap and left or
　　　(comp(heap[left], heap[right]) and left or right)
　　 heap_swap(heap, comp, son, idx, heap_down, son)
　 end
end

function heap_push(heap, comp, val)
　 table.insert(heap, val)
　 heap_up(heap, comp, #heap)
end

function heap_pop(heap, comp)
　 heap[1] = heap[#heap]
　 table.remove(heap)
　 heap_down(heap, comp, 1)
end

function heap_adjust(heap, comp, idx)
　 heap_down(heap, comp, idx)
　 heap_up(heap, comp, idx)
end

function comp(lhs, rhs)
　 return lhs[1] < rhs[1]
end

function sorted_keys(dict)
　 local keys = {}
　 for k in pairs(dict) do
　　 table.insert(keys, k)
　 end
　 table.sort(keys)
　 return keys
end

function push_word()
　 if #word > 0 then
　　 if #words < TOP_NUM then
　　　 heap_push(words, comp, {freq, word})
　　 elseif freq > words[1][1] then
　　　 words[1] = {freq, word}
　　　 heap_adjust(words, comp, 1)
　　 end
　 end
end

function try_save_dict(new_key)
　 dict_size = dict_size + (new_key and #new_key or 0)
　 if not new_key or dict_size > MAX_SIZE then
　　 local file = io.tmpfile()
　　 for idx, key in ipairs(sorted_keys(dict)) do
　　　 file:write(dict[key], ' ', key, '\n')
　　 end
　　 dict = {}
　　 file:seek('set')
　　 dict_size = new_key and #new_key
　　 table.insert(files, {'', 0, file})
　 end
end

for word in io.lines() do
　 dict[word] = (dict[word] or try_save_dict(word) or 0) + 1
end
try_save_dict()

while #files > 0 do
　 local file, read_ok = files[1]
　 if word == file[1] then
　　 freq = freq + file[2]
　 else
　　 push_word()
　　 word, freq = file[1], file[2]
　 end
　 file[2], read_ok, file[1] = file[3]:read('n', 1, 'l');
　(read_ok and heap_adjust or heap_pop)(files, comp, 1)
end
push_word()

table.sort(words, comp)
for i = #words, 1, -1 do
　 io.write(string.format('%d %s\n', words[i][1], words[i][2]))
end
```

@AoEiuV020JP 总感觉，Win10+ 有内存泄漏。。

表现为，用了几天后，关闭所有程序，但系统还会吃很多内存。。（比如一半以上。。）

Win7 、XP ，好像没有这种现象。。

@bthulu 楼上这么多人给出的方案，你给点反馈呀？

1. 全读出来，存数组里，直接遍历找
2. 全读出来，存哈希表里，精确查找
3. 全读出来，排序后存数组里，可范围查找
4. 全读出来，丢到 Redis 里，再查
5. 全读出来，每个丢到一个文件里，根据文件名查
6. 用 MySQL 内存表
7. 用 SQLite 内存表
8. 用 MySQL 存储过程写逻辑


个人认为，从速度上说，内存里用哈希表／ B 树／排序后数组二分查找，

＞ SQLite 内存表（这个每秒只能几万次）＞ MySQL 存储过程（页面缓存还是有些慢）＞数组遍历（ 99%无用功）

＞丢到 Redis 查（几千次网络开销）＞ MySQL 内存表（几千次网络开销）＞存几万个文件再查（几千次文件系统开销）

@WoodsGao #27 题目的原文件，应该是十进制字符串吧。。

就算是二进制数据，也应该是 8 字节，俩 int32 呀。。

https://i.imgur.com/krir4IG.png https://i.imgur.com/krir4IG.png

@wangpugod2003 #2 楼主，我突然对你的 10GB 文件感兴趣。。


假设你 10GB 二十亿条，那平均每条 (10 << 30) / 2e9 = 5 字节，

去除空格、换行 2 字节，还剩 3 字节，你是怎么存得下 10 位数的 ID ，和几位数的 value 呢？


https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@wxf666 #5 等会儿，我以为是，求出现最多次数的 ID 了。。

那你这个算法，应该没问题的呀？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

极端情况下，每个 ID 只出现一次，

你是要在内存里，保留整个 几百 GB 的 ID 吗？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@bthulu #3 键是宽度值，值是（库存 ID/引用/指针/…）数组？

或者，你也模仿数据库的底层存储结构，内存里也用 B 树存储呗。。

全读出来，存到 HashMap 里，不也相当于有索引了吗？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@ComplexPug #11

1. 噢，说错了，是 2048 长度的哈希表《数组》。https://i.imgur.com/krir4IG.png

2. 感觉你是想说，计算完一个文件后，就分别把 2048 个哈希表里的频率统计，追加到 2048 个文件里？

计算完所有文件后，再挨个频率文件，计算总频率，且始终只保留频率前 100 的字符串？

感觉这方法是准确的，但极端情况下，频率文件 > 内存限制时，会爆内存。

比如，所有字符串只出现一次，原文件大小 / 2048 > 内存限制了。。

或者，被恶意构造字符串了，使得所有 str.hash() % 2048 后，都挤在同一个文件内。。

@ComplexPug #9

假设你是单线程，计算完第一个文件里，每个字符串次数后，

你要对那 2048 长度的哈希表，做什么呢？


1. 啥也不干，继续算第二个文件？

（若原文件，每个字符串只出现一次，那你不就相当于在内存里，保留整个原文件了吗。。）


2. 遍历哈希表的，2048 个子哈希表，丢弃 100 名外的？

（若原文件，每个字符串出现两次，唯独一个字符串，出现 2048 次，但分散在每个分割后的文件里。岂不是会被你，每次遍历完一个文件后，丢弃掉？）


3. 我理解错了，等待你补充。。

为啥现在 Go ，不支持 Win8.1- 了呢。。

会不会明年 Win10 支持服务结束后，也只能跑在 Win11+ 上了呢。。

https://i.imgur.com/krir4IG.png https://i.imgur.com/krir4IG.png

@sudosu #43 微软不要它口碑了吗？

驱动都是要微软认证，才能运行的呀？

怎么系统设计，就不经微软允许了呢？

难道这只是驱动签名收费的一个由头借口？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@ComplexPug #7 关于第二个问题：

1. 直观上说，每个字符串都只出现一次，最后取哪 100 个字符串呢？

2. 假如说，题目保证肯定有 100 个字符串，出现次数最多。

那如果，我这样构造原始文件呢：

你分割的前 2047 个小文件里，所有字符串都只出现一次，
在第 2048 个文件里，100 个字符串出现两次。

你在构造哈希表，甚至每个分组统计 TopK 时，会不会要在内存里，保留几乎整个原始文件的字符串了？

那内存会不会爆炸了。。

Excel 不是默认不运行宏的吗？ https://i.imgur.com/F29pmQ6.png

@sudosu #2 驱动都要微软认证才能用，怎么系统就能任由某团队放飞自我了呢？