V2EX › ipwx 的所有回复 › 第 69 页 / 共 200 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 65 66 67 68 69 70 71 72 73 74 ... 200

❮

❯

2021-06-05 17:51:54 +08:00

回复了 ChovyChu 创建的主题 › 生活 › 想了解一下为什么奢侈品能让女生这么的向往

楼主你自己的钱，你给你妹妹买啥都是楼主你自己说了算。

你妹妹自己的钱，她自己买啥都是她自己说了算。

好，这题解决了。

2021-06-04 16:22:33 +08:00

回复了 yifangtongxing28 创建的主题 › 职场话题 › 是什么让大家坚持 9 点， 10 点，甚至更晚下班的

到点就撤+1

因为老板也是到点就撤

2021-06-04 11:40:56 +08:00

回复了 kensoz 创建的主题 › 程序员 › 上司不允许使用 es6 新特性理由是他看不懂

@marcong95 为啥感觉楼主说的是，他上司不用 lambda，只准用 for 。。。

2021-06-03 17:13:48 +08:00

回复了 iiq2000 创建的主题 › 程序员 › 请问存储百万条或者千万条抖音评论应该选用什么数据库？怎么设计？

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

2021-06-01 15:27:58 +08:00

回复了 MilkyWayne 创建的主题 › Apple › 请教， Capture One 可以取代 Adobe Lightroom Classic 么？

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

2021-06-01 15:26:58 +08:00

回复了 MilkyWayne 创建的主题 › Apple › 请教， Capture One 可以取代 Adobe Lightroom Classic 么？

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

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

2021-05-25 14:01:45 +08:00

回复了 PEIENYKYK 创建的主题 › 咖啡 › 迫于每天喝咖啡，请大家推荐，自动咖啡机还是胶囊咖啡机还是速溶？

https://item.jd.com/100013977054.html#crumb-wrap

2021-05-25 14:00:57 +08:00

回复了 qqqtz 创建的主题 › 问与答 › 你们都把 capslock 跟 ctrl 对调吗

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

2021-05-25 13:58:23 +08:00

回复了 longway 创建的主题 › git › 真有人觉得 Git 会提高生产力？

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

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

2021-05-25 13:55:54 +08:00

回复了 longway 创建的主题 › git › 真有人觉得 Git 会提高生产力？

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

2021-05-25 13:53:58 +08:00

回复了 longway 创建的主题 › git › 真有人觉得 Git 会提高生产力？

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

2021-05-24 23:05:14 +08:00

回复了 815979670 创建的主题 › 问与答 › 后端程序员有必要学 PostgreSQL 吗？

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

2021-05-24 17:09:02 +08:00

回复了 Phishion 创建的主题 › Python › 我想维护一个大型字典，有没有什么省内存的方法

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

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

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

2021-05-24 14:34:18 +08:00

回复了 Phishion 创建的主题 › Python › 我想维护一个大型字典，有没有什么省内存的方法

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

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

2021-05-24 10:16:06 +08:00

回复了 Phishion 创建的主题 › Python › 我想维护一个大型字典，有没有什么省内存的方法

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

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

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

2021-05-24 00:59:59 +08:00

回复了 Phishion 创建的主题 › Python › 我想维护一个大型字典，有没有什么省内存的方法

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

1 ... 65 66 67 68 69 70 71 72 73 74 ... 200

❮

❯