我自己开发了一个理念比较不一样的极简记录应用，已经用了快一个月，等功能更完备了后续也准备发布下。

@nanxiaobei 楼主自己就不是来讨论 git 的，他是已经有结论以后来说服大家 git 不好学，劝大家不要用 git 的

改自己泡茶喝吧，茶应该是减脂的

感觉楼主说的场景问题不在 git，而是开发模式，甚至只是代码组织和人员分工的问题

我一般用 virtualenv+pyenv

linux 桌面其实用起来还行，就是小毛病多了点，但是大部分也不能怪桌面，很多是驱动相关的问题，毕竟服务器相关的驱动都比较成熟了，但是桌面相关的驱动有关厂商都没有太大动力去折腾，所以综合考虑现在的桌面也还可以了。

我本来最讨厌 hell perl 这种有 $ 的语言，所以写脚本偏好用 python，然后你又在 python 里把$给整了出来，这个让我觉得一阵恶心，觉得 python 被 shell 污染到的样子。。。

对于焦虑我来推荐一本书《精神焦虑症的自救》
虽然是比较早的书，但是内容相当好，理念和方法很实用。觉得也可能和冥想之类的结合。
甚至有些关键内容和“无所住而生其心”感觉还是有些相通的，但是更容易理解和实践。

@namelosw Google 咋不用 git 呢，Gerrit 都是 Google 开发的。

Android 参考: https://android-review.googlesource.com/

坚持锻炼，每天几分钟锻炼肌肉类型的就够了，坚持半年脂肪肝就没了

风险在于你的私钥有可能被泄漏，比如你本地被恶意软件入侵，如果你为每一个 git 网站生成单独的密钥，那你本地被入侵的时候还是全部都被窃取了，安全性应该差不多。

或者你实在优化有问题，考虑把对象内的数据外包给 redis 处理，这样 python 这里只要做数据查询就可以了，不用面临这种 python 内部内存暴涨的情况

gc.collect 的参数调整没用吗？
另外不做 gc 的后果是什么？内存暴涨？能否重用 dict 之类的对象来减少新对象的创建？还有就是检测一下内存用量，超过临界值了再执行 gc 。

从 obj_find_one 的实现来看，应该是这个遍历耗时很长，看能否调整数据结构，让这个查询不需要遍历，或者看能否做预处理形成一个中间数据结构让查询不需要遍历。

gc.collect 的优化看看能不能不要每次都做,还有 gc.collect 的参数你看能不能给 0 试试 gc 效果如何。

你说解析函数有误导性，看起来其实这个函数不光做了解析还干了很多其他的事情，这里面有很多细节和可能性。
我的建议是仔细研究这个函数，看到底越来越慢是这个函数的哪一步导致的，如果能找到，那大概率能猜出是什么导致越来越慢。