双向链接都是基于超链接的思路，这种思路是对电脑很慢数据量大优化的。

我用过各种记笔记的方式，我的笔记即便加上 pdf 图片 也不会超过 1G，纯文本格式的聊天日志两年才 691MiB 。

这些数据量直接来一次不分词的全文搜索更方便。

vvbrfufehdibgiludllbnhhjhevgbjluetfvivjltiic

举个例子，找标准库里的 net/http

strings /proc/self/cmd | grep -P '^net/http\.'

可以运行的例子 go 编译器静态连接的 runtime net/http:

strings $(which go) | grep -P '^net/http\.'

提醒一下，一元硬币现在有兼容性问题，有可能需要刻意找旧版一块钱。

http://yuqing.people.com.cn/n1/2020/0515/c209043-31710919.html

-h 走 tcp socket. 不加走 unix domain socket.

Ctrl 按下 / a 按下 / a 抬起 / Ctrl 抬起 / Shift+/ (? 键) 按下 / Shift + / (? 键) 抬起

可以看到你当前所有的快捷键列表，C-a 意思是同时按下 Ctrl 和 a，空格代表上个操作松开。

假设你的 prefix 是 C-a 。

正确的按键顺序如下。

Ctrl 按下 / a 按下 / a 抬起 / Ctrl 抬起 / [ 按下 / [ 抬起

cosfs 应该不支持 range lock 吧

iPad mini 5 126
AMD 4750g Linux Firefox 71
Surface go Windows Firefox 22

> 而 Loki 底层存储的实现 Cortex 已经在实际的生产中投入使用多年了。

然而这个 cortex 就是问题。它本质是个时序库，而且有 prometheus 的所有限制（ 64G 文件大小，5M series 打爆内存等）

如果一个时序库能满足你存日志的需求的话，还不如选择更专业的时序库。

比如 influxdb 和 timescale 。或者其他私有的带压缩时序库是更好的选择，日志的 xz zstd 接口和浮点数压缩没多大区别。

面试完能了解到同事的社交网络账号，能 on-site 一下看一眼公司环境，公司有很多对外的宣传并且看起来靠谱

能提前消除信息不对等就行

第一种就是刻意写的难懂，刻意使用下标，合并一个数组用光的条件到主循环里，合并判断条件到控制里

```
template<class InputIt1, class InputIt2,
class OutputIt, class Compare>
OutputIt merge(InputIt1 first1, InputIt1 last1,
InputIt2 first2, InputIt2 last2,
OutputIt d_first, Compare comp)
{
for (; first1 != last1; ++d_first) {
if (first2 == last2) {
return std::copy(first1, last1, d_first);
}
if (comp(*first2, *first1)) {
*d_first = *first2;
++first2;
} else {
*d_first = *first1;
++first1;
}
}
return std::copy(first2, last2, d_first);
}
```

ref https://en.cppreference.com/w/cpp/algorithm/merge

version 3 就是刻意写的很难懂，cpp 标准库版本

template<class InputIt1, class InputIt2, class OutputIt>
OutputIt merge(InputIt1 first1, InputIt1 last1,
InputIt2 first2, InputIt2 last2,
OutputIt d_first)
{
for (; first1 != last1; ++d_first) {
if (first2 == last2) {
return std::copy(first1, last1, d_first);
}
if (*first2 < *first1) {
*d_first = *first2;
++first2;
} else {
*d_first = *first1;
++first1;
}
}
return std::copy(first2, last2, d_first);
}

@mengzhuo

错误处理分支没执行，也不是指令重排。
单纯的代码太多导致 l1i cache 变来变去

我知道 thrift 的 api 变来变去很难受。

但我想问你们是什么组，居然去搞这个。

cnvi 完全是为了垄断市场的接口，看不出有任何好处

在有 gc 的语言中一切常识都要重新考虑。

一个指针数组填充时需要 N 次内存分配，创建 N + 1 个对象。

写起来奔放的话 gc 导致的 cpu 使用会比程序真正用到的还要多。

STW 延迟还好，但是吞吐量就没有了。

这是 go 社区的特点

带着 fliter 数 count 就是这样子的

看你们团队谁强势
- 产品强势：就这么放着，等产品觉得慢，然后告诉他数总数花了 6 秒
- 开发强势：返回假的总数或者用游标翻页