should we swap out the hash table implementation?

[jonm]

There are 3rd party hash table implementations that are undoubtedly more battle-hardened and robust, such as the one in the Apache Portable Runtime (APR):

https://apr.apache.org/docs/apr/1.4/group__apr__hash.html

The APR is available via Homebrew as well as via yum on the production Linux box.

The idea is to have less of our own code to manage; this would also make it easier to introduce hash tables in other areas. For example, the mob and object indices likely want to be hash tables instead of a binary search array. There are also other parts of the code where a linear search though a list is done to find a particular mob, object, or character.

[dangitall]

I am definitely 👍 on getting rid of all that custom hash and binary search code. I do wonder though if we need a hash at all vs. linear searches. Should we pull it out and profile it first?

[jonm]

It is less of a performance issue for me and more of a code clarity issue. Maps are pretty well-understood interfaces, and when you are doing a lookup, that's really what you want. I do think performance should be addressed as a separate issue, though--it's clear the game has some serious pauses from time to time, even with only 1-2 players connected.

[dangitall]

Oh, I haven't noticed the pauses. You are signed on more often than I am, surely. I'm curious about where they are. The interface seems generally chunky to me but I've assumed that was just because of the slow event loop.

I feel like you're blurring the line between interface and implementation. Can't we have a hash/content-addressable API implemented with a linear search? But anyway, bringing in a reliable 3rd-party hash lib sounds reasonable to me.

[jonm]

You're right, of course re: interface vs. implementation. If we're going to have a hash table interface, I'd rather drop in a 3rd party implementation than write our own linear search implementation.

On pauses, my intuition is that this is due to structural / algorithmic problems rather than low-level inefficiencies. But that's just intuition. :)

[dangitall]

Well ok, but can we wrap the 3rd party API in our own abstraction?

[jonm]

Definitely. It's probably an outgrowth of the refactoring we'd need to do this anyway.

[JerrySievert]

if you're still working on this, I have a pretty good base (of the source code), and a very strong understanding of the sillymud code (I wrote a lot of it, as well as Phoenix its successor, and epic).

happy to help with at minimum history, and what we were thinking (I was running this on my amiga 500 for local development, for instance), and might be able to dredge up enough memory to help with code.

[jonm]

Hiya! I am not actively working on this--have been too busy. But I do think about it and would like to continue tinkering on it over time. Maybe I will open a few more issues so we can discuss things we'd like to do in case people have interest/inclination/energy etc.