Include hash_map

[Sydius]

I believe hash_map should be included.

It would only require including two additional header files. No additional libraries would be required. Any compiler that supports STL will support hash_map. Those two header files could be distributed with source distro and included like the other header file are.

Implementing it would require minimal changes. It works in a very similar way to a regular map:

SomeMap[serial] = SomeObject
SomeHashMap[serial] = SomeObject

In fact, replacing a map with a hash_map would only require replacing the line of code where the map is created.

The only down-side to using a hash_map instead of a regular map is that order is not preserved, but that wouldn’t matter in this case anyway.

The speed increase would be dramatic, since lookups of objects are done an incredible number of times in any given second.

Therefore, I think it is worth it.

[punt]

I don't understand your reference to support STL, as outside of the C++ Standard C++ Library , there are many different ones.

But hopefully it is as easy as you say (just headers, not all do that anymore such as STLPORT).

So I have the following:

main.cpp

Code: Select all

#include <map>
int main(int argc,char* argv[])
{
     std::map<int,int> testmap;
     return 1;
}

Ok, that will compile fine under gcc, and most compiliers.

Now, I believe your proposal is:

Code: Select all

#include <hash_map>   // Note the header change
int main(int argc, char* argv[])
{
     stdext::hash_map(int,int> testmap ;    // Note the namespace change for MSVC at least
     return 1 ;
}

That wont compile under gcc (nor under std:: namespace).
Did I miss something of your proposal?


I believe if one wants to do this, why woudln't one just use STLPORT for all compiliers (in the uox code anyway) ? That would sove many "hacks" that have been added as well for MSVC 6, plus would guarantee a single STL interface (and implementation). But anyway, if you could please mark up this code included so I could understand your proposal, I would appreciate it.

[Maarc]

I have a suggestion for you, before you actually implement this.

Try it.

The speed increase would be dramatic, since lookups of objects are done an incredible number of times in any given second.

A few things, first of all. We don't know the number of times that lookups are done in any second, and it will be very load dependent (busy areas or not, high player counts or not). That's an easy thing to do, though, just chuck a static long counter into ObjectFactory::FindObject(), and run the server for a while. Watch how it changes. But also remember it will get called a lot at startup, too, so you'd want to watch from once the server is ready.

And another thing... I don't see how you think the speed increase could be that dramatic. It's essentially already a hashed lookup based on serial (hash size of 2477), and rather than probing for a new point, we store a map collection within the same hash point. So you have a linear lookup O(1) followed by a map lookup O(log n). It might be cleaner/simpler code to use a hash_map, but I'm williing to bet it won't be signficantly faster.

But go ahead, try it, see if it makes a practical difference, just remember there are potential problems (as Punt mentioned).

As for Punt, I agree, using STLPORT would be one way of avoiding such odd compiler issues. But that requires (like any library), the need to download and install another package, and makes the compile process more complex. We do need to trade off ease of access vs needs of the project, it's just a very complex decision to make. But STLPORT, to me, is bigger than say things like NSPR or boost, mostly because of how it essentially replaces such a low-level component of the compiler.

[punt]

Given the stated desire to support mingw, gcc(linux), and msvc 7 (not sure about msvc 6), I now appreciate what you where saying earlier about two line changes.
I earlier asked you what changes for this code had to be done:

Code: Select all

#include <hash_map>   // Note the header change
int main(int argc, char* argv[])
{
     stdext::hash_map(int,int> testmap ;    // Note the namespace change for MSVC at least
     return 1 ;
}

Ok, one would have to do a little defining for the different platforms, but you are correct, the line changes are trival:

Code: Select all

#include <ext/hash_map>   // Note the header change
int main(int argc, char* argv[])
{
     __gnu_c::hash_map(int,int> testmap ;    
     return 1 ;
}

So yes, getting hash maps would be trival, I now appreciate what you where saying.