啊这……

请容我多嘴一句：slotmap与关系数据库其实已经只有一步之遥了
啊。

关系数据库里的“关系”，基本形式就是：我的字段里存着你的id
（像极了array index），我就记住了你与我的关系。

而一旦用上关系数据库，至少就可以立刻用上数据库提供的id索引。
从线性寻址变成B树寻址，这对性能是有很大益处的。

而对于数据一致性问题，transaction可以帮上一些忙，虽然可能
不能全都轻易解决。

读写硬盘确实比较慢，但可以使用内存数据库嘛。

总之，当我们的业务需要对几百万条关系复杂的数据进行管理的话，
那么我们干的其实就是数据库的活。即便硬挺着不用数据库，迟早
也要把数据库面对的种种挑战都自己解决一遍。

当然，这只是我的一家之言……




另外，关于“所有权树”，我其实有一点不同的想法。我觉得，
rust和modern c++所讨论的所有权，它不是形成一个所有权的树，
而是所有权的流，是个flow。

其中一个很典型的现象就是，一个函数，接受输入参数，返回结果
值，这个结果值的所有权，也一起返回了，交给了调用者。

这些数值、数据结构，进而投入新的运算，把所有权交出去，然后
得到返回值，也拿到了新值的所有权。所有权就这样流动，用完了
以后就被RAII回收。这样的做法，全程都是const的，旧值不变化，
新值被产出，这是符合很多数学计算思想的思维方式。

我猜想，当我们在设计布线的时候，或许：旧的布线是一种输入，
新的元件需求是另一种输入，进而，新的布线是计算得到的输出。

所有权是在旧的值到新的值之间流动，每一个值（布线方案）都是
一个对象，旧的对象被RAII回收，新的对象投入更多的计算与优化。

但是每一个此类对象，一旦生成，就不会变化，不必再有&mut发生，
也不会有用到Rc的需求。

这样或许可以节省许多心智开销，而且性能方面吃亏很少。



【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: EDA方面的项目，典型场景是要构建一个层次化的几何体的树，在里面用各种算法去布局布线，也就是调整几何体的位置、增加用于连线的新几何体、检测矩形碰撞、连通性等等。典型规模大概在几百万个矩形这个量级上，或者更大。
: 是的，这个主题开头几个帖子我也表达了对Rc性能的担心。而且用Rc<RefCell<T>>写了两周，已经出现了较难控制的循环引用内存泄漏问题。
: 现在倾向于使用slotmap这类的arena方案，就是用array index来代替指针/引用/Rc。性能损失也是会有的，因为毕竟中间多了一次根据下标做线性寻址的操作，slotmap这类方案为了避免ABA问题，还要额外储存version信息并且比对。直觉上这个和Rc+RefCell相比，性能损失应该差不
: ...................
--
修改:wolfgang FROM 101.88.39.*
FROM 101.88.39.*