从我读到的,Orddict只是一个关键的价值存储.
我遇到了诸如商店,发现,映射等术语,并意识到除了存储价值之外,还有更多的东西要求.
但在一般情况下,何时可以使用orddict？
orddict基本上是[{Key, Value}]对的列表,但元素都按Key部分排序.与使用简单的未排序[{Key, Value}]对列表相比,这使得查找更快,因为在排序列表上定位某些内容可以从高级搜索算法中受益.
更具体地说,使用普通的proplist你不可能知道任何密钥相对于另一个密钥的最近位置,所以跳到列表中间寻找特定密钥与简单地从开始到结束检查迭代没有任何优势.每个键按顺序排列(事实上,跳跃而不是头到尾会产生开销).但是,使用orddict,您可以检查中键,确定目标键是否大于或小于那里的值,并知道是否在中键之前或之后搜索,从而大大减少搜索/比较的数量执行.(例如,考虑二元搜索与搜索随机索引窗口的效率,两者都大大超过了迭代比较.)
所以它实际上是一个效率问题,而不是存储大小甚至语义的问题(大多数时候你会在模块内部使用这些结构,模块的界面是外界所能看到的 - 这有点静音了proplist和orddict接口不同的效果/烦恼).
您在orddicts上发现常见的功能列表操作反映了两件事:它们实际上是列表,并且界面提供了现成的方法,既允许您使用orddict接口,也可以将orddicts实用程序保留为完整列表.(不要将orddicts视为原始列表 - 你最终会让自己哭泣.)
proplist模块中有未分类列表的自然界面.提示者似乎足够有效,我没有注意到短于15项左右的列表有任何优势,但除此之外,排序搜索的效率克服了orddicts的开销.Orddicts占据至高无上的约100项左右(Fred Herbert实际上在他的书中说了75 - 但我自己没有运行基准测试).除此之外,你将要寻找合适的字典,树,或索引表结构-你真的必须基准你的使用情况,发现这是最有效的("做我[写入/更新/删除/读取/复]查询对于[可变大小]的结构,我需要[持久/短暂]并且在N个节点失败时保证稳健吗？"等等.
在实际应用中,我发现自己使用orddicts来获取短数据集,当我开始遇到效率问题时,它几乎总是意味着我不仅已经超出了orddict,而且还超出了我系统内置的其他限制(通常我有由于没有意识到我真正需要一个数据服务而不仅仅是一个排序的事物列表而引入的瓶颈.例如,如果我在一个有玩家和物品的泥泞中有一个房间,那么房间可能会跟踪两个作为orddicts的列表.如果我在业务应用程序中有一个库存项目列表,其长度可能是数千个条目,或者在Postgres或ETS表中(或两者都有,则ETS表是查询数据的"工作副本",仅存在于客户端的内存中,Postgres是一个更受控制的耐用商店).