es 不就干这种事么，而且还能做全文检索。。。多好

LR 搞完调色，然后进 PS 液化、磨皮（ Imagnomic Portratuire ）、修瑕疵（中性灰等手段）一条龙很爽的。

Lightroom 照片管理 + 修图，然后右键 Photoshop 打开，爽歪歪。

而且关键是 HSL 和 三原色 的条块对人像修图（肤色调整）太好用了

可能是我手大，按 ctrl 挺自然的没问题。

@longway 高效的大项目（也是 git 适合的场景）：每个组负责不同的子系统、组内每个人负责不同的子模块。每个人负责的文件都不一样，哪来的冲突机会？组和组之间的接口由总架构师协调，组内由组长协调。架构师干嘛的？不就是干这个的吗？

你一坨浆糊当然一直冲突…… 而且还没法开发更大的项目。

@masterclock @jones2000 所以就是楼主 @longway 团队的合作方式有问题啊。如果每天都有大量 conflict，说明根本没有进行团队工作切分，都是临时给人派任务。。。。这妥妥的缺少个架构师

1. 你得用 branch 。branch 功能特别爽，每个人独立开发个把月，最后合并就行了。
2. 如果你们不能用 (1) 的方法工作，说明你们团队每个人的功能划分太奇怪了。哪有这么多的一起修改同一个文件的情况啊？这哪种工具都高效不起来啊喂。你们得有分组分层责任划分，每个组每个层和别的层除了接口其他互不相关才行啊。

很多时候 MySQL 要有经验地写法才能避开的坑，Postgres 的查询优化器已经帮你解决了。PG 能够高效运行的子查询的种类比 MySQL 多得多。所以，很多情况下，Postgres “不用学”。

@lujjjh 虽然你说的对，这个场景的冲突概率很低，但是并没有低到 2^(-128)。这是典型的生日问题，因为你的问题不是给定某个特定川，表里面有川和它冲突的概率，而是表里面有任意两个串冲突的概率。

https://en.wikipedia.org/wiki/Birthday_problem#Probability_table

这里写出来结论了，超过 p=0.001 有任意两个串冲突，表里面需要有 8*10^17 个元素就行。

@lujjjh 哈希只能是概率性不冲突啊，虽然概率小，但是不能保证程序**一定**正确不是么？

楼主没有讲可以概率性正确，你这就加上这个条件，这不好。

@ZhangZisu 但其实哈希表用平方探测不是只要两倍内存就基本能保证性能么。。而且两倍的是哈希表节点而不是字符串。用上 StringPool + string_view 咱觉得基本就是最好的方案了。

@Phishion 咱多少觉得，楼主有种 XY Problem 的感觉。到底什么场景下 400MB 的表都会 concern ？是不是和多进程有关？ Linux fork 的话，因为内存使用是 COW 的，所以可以主进程创建完整个表，然后子进程就不用创建第二份了。

那如果是设备内存太小，或者本身楼主要处理的不是 400MB 而是 40GB 这种场景，那可能就需要使用 disk-backend 的数据结构了。比如 B-Tree 。

@ZhangZisu 我觉得楼主这个需求，trie 树不太好用。因为楼主的字符串是真随机，trie 树每层都会分出一堆节点，基本是个满 K 叉树，比一个大哈希表用更多内存

@Phishion https://developers.digitalocean.com/libraries/

楼主估计说的是这里，Official API 只有 Go 和 Ruby，其他的是社区提供的。

但是，这难道不能说明其他语言社区比同时期 Go/Ruby 好很多，所以官方都不用动手就有 Binding 了吗 。。。。

也许版本不对标错了的话，你可以再看看

https://hub.docker.com/layers/haowenxu/ml-runtime2/gpu-cuda10.1-cudnn7-py3.6-torch1.5.0