我一开始有严重的鼠标手，经常玩几个小时电脑后手腕要疼一两个小时，根本没法工作。后面换了罗技的一款轨迹球，用了 1 年，好转了很多。再后来换了 mac 只用触摸板，现在 2 年了，鼠标手没再犯过。

发现 v 站代码格式都混乱了，推荐去上条回复中的 github 链接查看

最近在看 《 Python 源码剖析》
类似 [obj] * count 的表达式，编译成字节码之后为

```
# 构建 [obj]
0 LOAD_GLOBAL 0 (obj)
2 BUILD_LIST 1

# 读取 count
4 LOAD_GLOBAL 1 (count)

# 实现 [obj] * count
6 BINARY_MULTIPLY
```

而 BINARY_MULTIPLY 指令在源码中的实现为

```
TARGET(BINARY_MULTIPLY) {
PyObject *right = POP(); # 获取 count
PyObject *left = TOP(); # 获取 [obj]
# 获取相乘的结果
PyObject *res = PyNumber_Multiply(left, right);
Py_DECREF(left);
Py_DECREF(right);
SET_TOP(res);
if (res == NULL)
goto error;
DISPATCH();
}
```
而 PyNumber_Multiply 最后调用的是 ->ob_type->tp_as_sequence->sq_repeat 函数，

```
# repeatfunc = sq_repeat
# seq = [obj]
# count = count
return (*repeatfunc)(seq, count);
```
该函数在 list 类型的实现为

```
static PySequenceMethods list_as_sequence = {
...
(ssizeargfunc)list_repeat, /* sq_repeat */
...
};
```

下面是 list_repeat 简化后的代码

```c
static PyObject *
list_repeat(PyListObject *a, Py_ssize_t n)
{
...
PyObject *elem;
# np 指向新分配的 count 大小的 list 对象
np = (PyListObject *) PyList_New(size);

items = np->ob_item;

# 如果 [obj] 的对象大小为 1 的话，我们这里就是如此
if (Py_SIZE(a) == 1) {

# 获取 obj，即这里的 elem
elem = a->ob_item[0];

for (i = 0; i < n; i++) {
# 因为 elem 是指针，所以这里新的 list 的 items 里面包含的是原有的 obj 的引用，而不是复制
items[i] = elem;
Py_INCREF(elem);
}
return (PyObject *) np;
}
...
}
```

所以 [obj] * count 最后获得是包含 count 个 obj 引用的新 list

在 github 上写了一篇 blog，更加详细的论述了这个问题，有兴趣的可以点击观看

https://github.com/shidenggui/blog/issues/16

对昨天写的 union find 做了下 performance，时间复杂度约等于 O(N)，下面是结果。具体测试代码附在上面的 gist 里了。

union-find:
K rows: 100 N: 63196 time: 79 T(N)/O(N): 799
K rows: 200 N: 126404 time: 149 T(N)/O(N): 848
K rows: 400 N: 252847 time: 298 T(N)/O(N): 848
K rows: 800 N: 506194 time: 600 T(N)/O(N): 843
K rows: 1600 N: 1012045 time: 1214 T(N)/O(N): 833
K rows: 3200 N: 2024459 time: 2481 T(N)/O(N): 815

https://gist.github.com/shidenggui/933213ff4d1abfa142923ed766544112

用 union-find 写了下，感觉并不是最优的。

这个应该是属于 external sorting 里面的 k-way merge。下面的算法来自《 Data Structures and Algorithm Analysis in C 》:

首先令 N = m * n 表示所有需要排序的量，M 表示内存能容纳的最大数据量。

然后在内存中维护一个最小堆，第一次读 M / m 个节点，将最小堆填充满，然后每次 pop 一个最小的值依序写入到对应的节点中，这时内存中会多出一个空位，此时可以继续读取数据，如果读取的值大于 pop 出的最小值，则将其加入最小堆参与这一轮的排序，否则将其留在 pop 出最小值后留下的 dead space 中，等待下一轮排序。

这里有一个问题是每个节点应该写入多少次排序好的数组呢？比如都写入一次，则需要读取的节点数太多了。根据书上的方法，根据 N / M 估计第一次排序产生的数组数量，然后计算 kth order 斐波那契数列。比如有 N / M 为 34，两个节点，则第一个节点写入 21 组，第二个节点写入 13 组。

然后按照同样的逻辑不断归并，最后就可以得到一个有序数组。

整体算法复杂度为 O(Log_k{N/M})，k 为节点数。

@YvesX 结尾只是感慨下，有时候知道数学结论跟能从问题中正确识别到对应的数学关系，其实之间还是有一段距离。

@cxw3292008 没了，最近在忙其他的事情。可能有空会重启下这个

我几年前也有过胃病。以前几个月不吃晚餐，然后有一天冬天骑自行车腹部吹了冷风，突然就发病了，每次吃完东西都腹部鼓胀、疼痛加上强烈的下坠感，几个小时都好不了。熬了几周没坚持着，准备去看医生了。不过我后面的流程跟你不太一样，我找了一个厦门的经方派中医（经方的意思是指主要依赖于几千年人体实验下来有效的药方，类似日本汉方，而不太依赖中医理论），他给我开了几幅理中汤，喝了几天后明显好多了。在后面就靠自己调理了，恢复正常饮食，加上跑步、减少肉食，基本没太多影响了。主要感觉跑步对肠胃改善特别大，经常跑步基本上以前胀气、不定时吃饭就胃疼这些都消失了。

用过半年，很大程度上缓解了我的鼠标手。后面全部改用触摸板就弃用了。

漏了一条，自带 go fmt，省心省力，再也不用纠结代码格式的问题了

我以前在一家做图像分类的公司完整经历过 Python 转 Go。
最开始我们的业务架构是 all Python，api 服务使用 flask + celery + redis + mongdb + 基于 thrift 的 C++服务， 处理简单的图片分类。
转的原因：后面来了一个业务需求，对 api 的响应速度和 qps 都有要求，基本上是几千 qps 每秒。因为本身的业务逻辑比较简单，所以我们 profiling 了下，发现瓶颈在 Python 本身。我以前用过 Golang，所以基于 Gin 框架实现了一个简单的业务逻辑进行压测，发现性能比 Python 好很多，达到我们的预期。

## 工程效率对比：
* 一个是响应时间快了不少，Python 的话能优化的空间有限，而且效果也不是很理想
* 单机支持的 qps 提升很多，不需要增加线上的机器就可以满足新需求
上面这两个提升基本是 5 倍左右吧，具体记不清了

然后我们基于 Golang 实现了原来的鉴别服务，达成了项目需要。

## 遇到的坑：

* 包生态还不完善。我们重度依赖 Celery，Golang 当时没有类似 Python Celery 这个库，所以只能参考 Celery 的原理实现一个类似的。还有一些基于 Pandas 的代码还是保留 Python 版本。
* Golang 的包版本管理以及下载比较麻烦，本地有代理还好，线上部署如果是实时拉代码的话很麻烦。后来我们把需要的库都本地打包到 docker 镜像里作为 base image。

## 其他收益

相比 Python 好的地方
* Golang 的类型检查和基于防御性编程的错误处理方式，减少了很多 Bug 发生率，不像 Python，有时候一个错误会传递很深
* Golang 的 goroutine 加 channel 在实现一些跟并发相关的控制逻辑时非常简洁
* 对重构友好，完善的语法补全、定义跳转。我们的 Golang 项目都是用 vim 写的，基于 vim-go 插件，基本可以达到跟 ide 一样的效果，用 Python 的话基本不敢想象比较大的项目离开了 Pycharm 后面会变成怎么样
* 编译速度快，支持跨平台编译，部署方便，内存占用低，长时间运行非常稳定
* 自带 profiling 工具，性能分析方便

跟 Python 比不足的地方
* Golang 开发效率的降低，主要是内置库没有 Python 丰富加上需要类型的缘故，会稍微繁琐一点。目测开发相同功能应该是降低到原来的 1/2 或者 1/3。但是如果算上 Golang 带来的 Bug 提早发现减少的后续开发维护工作的话，我感觉并没降低太多。毕竟修 Bug 是个很蛋疼的事情，尤其是 Python 这种
* 测试麻烦。Python 有 mock，写测试还是比较舒服的。但是 Golang 的话，如果没有一开始就基于 interface 去思考这个代码怎么测试的话，后续写测试很蛋疼

零零碎碎就记得这些了，可能有些随着时间流逝外加 Golang 生态圈的变化已经失效了，列在这里仅供楼主参考

@revival83 我也有鼻炎，不过运动加控制体重加尽量素食之后缓解了很多。

@Willjim 可以推荐他去医院检查或者领个呼吸机试下。呼吸障碍供氧不足，越睡越累

淘宝搜 apex 硅胶耳塞。我以前住在繁忙的马路边，不带耳塞睡不着。我用过安尔悠、3M，但是入耳式的长期带耳朵后面会疼、发痒。apex 这种属于非插入式，黏在耳朵旁边密闭耳道的，效果也不错，就是使用期比较短，偏贵，我以前连续带了 3 个月没有问题。
如果有呼吸障碍的话可以去医院做个测试，不然长期下来人一直供氧不足，会很疲倦。
或者嫌麻烦的，上海应该也有那种呼吸机的专卖店，都是可以免费试用几天的的。你去领台试下，晚上机子会记录你的呼吸暂停情况，然后你发给服务商，他们也可以帮你做个简单的分析。或者你试用之后感觉睡眠改善了很多，那你可以考虑购买一个

投递了，现在主要以 Python 为主