View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000639 | LDMud 3.3 | LPC Language | public | 2009-05-22 02:24 | 2009-05-22 03:16 |
| Reporter | lynx | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Product Version | 3.3.718 | ||||
| Summary | 0000639: hash table data type? | ||||
| Description | Congratulations LDMUD team for cleaning up most of the bugs that had accumulated in mantis! Looking forward to try out the fixes and hoping for greater stability! Time for an actual old-fashioned feature request.. or rather, an inquiry. I noticed ldmud only runs a few real hash tables.. like the object name table and the shared string table. Things that one imagines to be hash tables like mappings and switches are actually implemented by binary trees or similar. This sure made sense in the days of tight memory conditions, but not all of us have to consider memory over performance. Turning switches into hashes is probably pointless, unless we can make very good use of the fact, that we know how many elements are in the switch. Our "mudlib" uses lots of extralarge switches. Having an option to compile mappings as hashes would affect the behaviour of an ldmud application dramatically.. might be an interesting thought. The completely-in-control option would be to have an actual 'hash' data type which behaves pretty much like mappings, but uses more memory and gives you more performance in exchange. We'd probably consider rewriting some of those huge switches into shared hashes, if the performance is worth it. I bet every mud these days has a bunch of large central mappings and switches that may be worth implementing as a hash instead. But maybe I'm completely naive on the actual performance gains and the whole thing being worth the hassle. | ||||
| Tags | No tags attached. | ||||
|
|
Mhmm. Some short first comment concerning the mappings: they are implemented as a kind of hybrid containing a hashed part and a condensed part. All changes end up first in the hash part and are being compacted by the backend after some time without additions/deletions. This time is configurable (TIME_TO_COMPACT, typically 10min), although not by configure right now. If you really want to have mappings contain only the hash table, you may try to set this time really high for the moment (although a garbage collection compacts them nonetheless). It would be interesting to make a benchmark with mappings containing only the hash part ('dirty' mappings) and with mappings fully condensed... |
