I understand that you guys want me to use hash maps instead of what I currently have. However hear me out, and I may sound crazy. But, I like my way
switch (hash(t.c_str())) {
case hash("READY"):
session_id = json::getValue(d->c_str(), "session_id");
onReady(d);
ready = true;
break;
case hash("RESUMED" ): onResumed (d) ; break;
case hash("GUILD_CREATE" ): onServer (d) ; break;
case hash("GUILD_DELETE" ): onDeleteServer (d) ; break;
case hash("GUILD_UPDATE" ): onEditServer (d) ; break;
case hash("GUILD_BAN_ADD" ): onBan (d) ; break;
..... to be continued or whateverOther then that, here's the thing about why I think people are telling me about. I think it's because of Collisions, which is when a result of a hash gets the same value as another value causing issues. If I'm wrong that because people just told me that it's bad and I don't know why because that's all they told me. However, I'm not worried about collisions because the more possible numbers that the hash can be, and the less values you have for the hash map, the less likely you are going to run into a collision problem.
However, I think I know why gperf is faster. It's hash function avoids using as little chars as it can for hashing, Plus each it does use a char to hash, it only needs to run a few lines of asm to do so. The hash function doesn't relie on a loop for hashing, and instead it uses a switch statement without any breaks. This all makes a nice hash function and it also does a good job at not having any collisions.
Ok, now that's why I think it's fast. However, this is from memory I didn't look into it again just now.
However, The bottleneck is this
constexpr unsigned int hash(const char* key, unsigned int i = 0) {
return !key[i] ? 0 : (hash(key, i + 1) * 31) + key[i] - 'A';
}Looking at the results I can see that using smaller values makes mine nearly just as fast as gperf from what I remember. So, I think that by updating the hash function and using the similar optimization that gperf is using. I'm positive that mine's should be just comparable in speed to gperf.
You might say "what if you do get a collision?". that's not going to happen, because discord uses a set number of strings. "BUT what if discord updates, and the user is using an out of date version of your library?" Good thinking, but even if that happens, it's not likely to get a collision because of the reasons above.
Ok, one last reason. It's simple to set up. having to use a normal hash map, would mean that I would need to make some changes in how my library handle most events. The way I listed above is simple to implement as I wouldn't need to make a new class and array for hold the t from the DISPATCH op and the function pointers to functions. Oh yes and some events need more then one function for an event. So one implement that is still not simple to implement, but it's the simplest one I came up with is to hold one function pointers (that are not lambdas) for each t from the DISPATCH op. This is because events are protected functions that you get from inheritance of the Sleepy Discord Client. I don't think I explained that very well but it's the best I can do because this is a discord message and you guys are complaining.
I don't know how many times @IntoxicatedHippo#0543 is going to tell me about this. But please, keep going, it's not a bad thing. I like that you want to help and thank you for it. But I will not always take everyone's feedback, I can choose. But I do listen, and I do value feedback a lot. Other then that I'm getting tired of talking about hash maps.
good shit