STL provides map support, and a natural choice for key is
string under many circumstances. However, the performance of
string is weak comparing to others. Let's test it first (using this test program) and see the results from a
550-MHz Celeron ThinkPad:
|Key type||MSVC 6||MSVC 6 (
||MinGW 1.1||MinGW 1.1 (
It is clear that in whatever compilation mode and using whatever compiler string is at least 10 times slower than int or const char* as key of map. It makes things inconvenient. One has to decide between performance and ease of use. Any good solutions to this problem?
One method is to use a short string as an integer. For me, I chose the 64-bit integer, and thus allow for an 8-character string. The simplest definition might be
wherein ULONGLONG is the type definition for 64-bit unsigned integer on a specific platform. The updated test program is here. The results show that accessing
mstring(const char* sz)
strncpy(chars, sz, 8);
std::less<mstring>::operator()(const mstring& x, const mstring& y) const
return x.index < y.index;
map<mstring, ...>takes only one ninth to one fourth of the time accessing
map<string, ...>takes. On MSVC 6 it is optimized so well that it takes only twice as much of time as
For a big-endian machine it should work perfectly. For a little-endian
machine you will find the sort order a mess. I will not explain much about
it but instead give my solution. You could have a look at my complete
It also includes overridden operators,
ostream support, and hash_map
HAVE_HASH is defined or
either SGI or STLport has been included). Many MinGW mailing list subscribers
should be able to tell why I asked some silly questions about template
specialization some time ago.
All code here is considered in the public domain though I do wish my name could be retained if anyone uses them. :-)
2002-2-24, written by Wu Yongwei.
This work is licensed under a Creative Commons Attribution-Share Alike 2.5 Licence.
Return to Main