@hiboluo 谢谢，还有其它网站吗？

活动行也是可以了，搜索关键字 “数据库”，第一个结果居然是白人相亲会 :D

click

在办公室工作也要调整好步调，能可持续发展，不为拿高薪，不为和大家比

为啥不能加索引

都学

vi + pycharm

感觉你写的对啊

不是青轴就行了吧 :D
我会小心不吵到别人，现在用的黑轴，中午休息时也放心用

觉得没说清楚，补充一些

情景是，有一批文本，先用算法预标注，再给人工改标注。人工需要知道每条文本的来源和种类，这就要把这些信息和文本拼在一起，最后再转化回原始文本。加信息和转化回原文本，都有随着文本一起改动标签的需求。

最近这个项目枯萎了。工具到这个程度，它适用的范围也不能小规模论证了。所以想请 nlp 专业人士和爱好者们一起打磨这个想法。

把 linux 当作开发机免不了经常折腾。
就是在这种折腾当中，了解关键概念、原理、实现，最后解决问题，得到提升。

服务器一旦上线，倒不用像开发机这样经常折腾，因为服务器以稳定服务为第一要务，软件升个级都是需要多人配合、尝试的“大事”。

学习、练习的话，用虚拟机或者 docker 会方便一点。

如果只想省事，不如直接用 windows。

因为程序和工程上这些概念，英文一看就明白了，中文看了还得反应一会。而且同一个词，每个软件的翻译还不一定一样。

都挂了还同步什么。。
我怎么觉得他是想问挂了以后怎么恢复？

git 完全可以

多谢 pympler 这个工具推荐
我搜 python memory profile and debug，为什么没搜出这个工具呢，只看到了 line profiler，heapy 啥的

这样搞是一个思路了，很笨的一个思路呵呵，很慢，跑十几分钟才跑出十分之一：

```python
from pympler.asizeof import asizeof

h0 = hp.heap()

ds = h0[0]

# 获取"根"dict set
root_ds = (ds - ds.referrers).byid

# 看一看每个“根 dict ”的 recursive size
sizes = []
for i in range(len(root_ds)):
info = i, asizeof(root_ds[i])
sizes.append(info)

# check size
```

我感觉这个测量是靠谱的
greenlet 虽然把 call stack 弄得“支离破碎”，但很有可能，在每个时刻对解释器来说是能够还原出当前线程的信息的。
所以说，图最右侧的是真正的 io 时间。这段时间内，gevent 发现，所有协程都阻塞住，没有任何一个能够继续往下走。
你那张图，如果用 top 观测 cpu rate，应该在 20%左右。当然也有可能不止，因为图上的 idle 也有可能在 run cpu，只是 pyflame 没法测它。


当然我说的不一定对。python 实现，greenlet，pyflame 的机制还要了解更多才知道。

@monsterxx03 我没有 idle，但是 wait 很长，像你的图右侧一样。不知中间的那部分是否有参考性。
没有 google 到什么解释。大概只能从二者的原理入手来理解了吧。

@monsterxx03 我在火焰图上没看到 idle. top 显示的 idle 还是比较高的,因为我的程序主要慢在,io 太多,且 io 和 cpu 是串行的,cpu 在等待 io.所以 cpu 利用率很低.

所以我打算引入 gevent 了.用 coroutine 先把 cpu 占满.
引入 gevent 之后,pyflame 还能用吗?我还没有试呢.
按照我的理解,greenlet 的实现,是自己维护了以及 process 运行的必要环境,比如各种堆栈;switch 时在自己维护的环境和真实环境中相互 copy.所以 pyflame 应当还是可以 work 的.这个理解对吗?