<p>I'm using a <code>std::map</code> (VC++ implementation) and it's a little slow for lookups via the map's find method. </p>

<p>The key type is <code>std::string</code>.</p>

<p>Can I increase the performance of this <code>std::map</code> lookup via a custom key compare override for the map? For example, maybe <code>std::string</code> &lt; compare doesn't take into consideration a simple <code>string::size()</code> compare before comparing its data?</p>

<p>Any other ideas to speed up the compare?</p>

<p>In my situation the map will always contain &lt; 15 elements, but it is being queried non stop and performance is critical.   Maybe there is a better data structure that I can use that would be faster?</p>

<p>Update: The map contains file paths.</p>

<p>Update2: The map's elements are changing often.</p>

The first thing is to try using a hash_map if that's possible - you are right that the standard string compare doesn't first check for size (since it compares lexicographically), but writing your own map code is something you'd be better off avoiding. From your question it sounds like you do not need to iterate over ranges; in that case map doesn't have anything hash_map doesn't.
It also depends on what sort of keys you have in your map. Are they typically very long? Also what does "a little slow" mean? If you have not profiled the code it's quite possible that it's a different part taking time.
Update: Hmm, the bottleneck in your program is a map::find, but the map always has less than 15 elements. This makes me suspect that the profile was somehow misleading, because a find on a map this small should not be slow, at all. In fact, a map::find should be so fast, just the overhead of profiling could be more than the find call itself. I have to ask again, are you sure this is really the bottleneck in your program? You say the strings are paths, but you're not doing any sort of OS calls, file system access, disk access in this loop? Any of those should be orders of magnitude slower than a map::find on a small map. Really any way of getting a string should be slower than the map::find.