Python的shelve模块是否使用内存映射IO？
有谁知道Python的shelve模块是否使用内存映射IO？
也许这个问题有点误导。我意识到 shelve 使用底层 dbm 风格的模块来完成它的肮脏工作。底层模块使用 mmap 的可能性有多大？
我正在制作一个数据存储的原型，虽然我意识到过早的优化通常会令人不悦，但这确实可以帮助我理解设计中涉及的权衡。
Does anyone know if Python's shelve module uses memory-mapped IO?
Maybe that question is a bit misleading. I realize that shelve uses an underlying dbm-style module to do its dirty work. What are the chances that the underlying module uses mmap?
I'm prototyping a datastore, and while I realize premature optimization is generally frowned upon, this could really help me understand the trade-offs involved in my design.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Python 标准库中现有的 dbm 实现都使用“普通”I/O，而不是内存映射。您需要使用内存映射编写自己的
dbmish 实现，并将其与shelve集成（直接集成，或者通过anydbm更高效地集成） >）。Existing
dbmimplementations in the Python standard library all use "normal" I/O, not memory mapping. You'll need to code your owndbmish implementation with memory mapping, and integrate it withshelve(directly, or, more productively, throughanydbm).我不确定你想通过问这个问题来了解什么，因为你似乎已经知道答案：这取决于实际使用的 dbm 存储。他们中的一些人会使用 mmap——我希望除了 dumbdbm 之外的所有东西都使用 mmap——但那又怎样呢？搁置中的开销几乎肯定不是在 mmap 与 fileIO 选择中，而是在 pickling 操作中。在任何一种情况下，您都无法自己明智地映射 dbm 文件，因为 dbm 模块可能有自己的奇特锁定（并且它可能不是单个文件，就像它使用 bsddb 时一样。）
如果您只是在寻找灵感对于您自己的数据存储，不要考虑搁置，因为它所做的只是腌制并传递到另一个数据存储。
I'm not sure what you're trying to learn by asking this question, since you already seem to know the answer: it depends on the actual dbm store being used. Some of them will use mmap -- I expect everything but dumbdbm to use mmap -- but so what? The overhead in shelve is almost certainly not in the mmap-versus-fileIO choice, but in the pickling operation. You can't mmap the dbm file sensibly yourself in either case, as the dbm module may have its own fancy locking (and it may not be a single file anyway, like when it uses bsddb.)
If you're just looking for inspiration for your own datastore, well, don't look at shelve, since all it does is pickle-and-pass-along to another datastore.