Usage of std::map/unordered_map and std::string hinders performance

See this talk from Herb Sutter: https://channel9.msdn.com/Events/Build/2014/2-661 for full context (relevant part is around ~45:00)

std::map (or list) will chase pointers and chasing pointers is death to perf. vector is an array, and arrays are very fast, esp. for linear access. If you need to look up something in a map, people think "oh but the big O of lookup is ! It's so fast!" - but the reality is that chasing pointers kills big O on modern processors. Linear searches of vectors is VERY fast, it has silicon optimizations at this point. So in general, if you have even up to thousands of elements, just linearly walking an array/vector is still great. It sounds counter-intuitive to just walk like that but it's fast.

bottom line: In our usage cases, map and unordered_map are bad because the number of keys is pretty low (<<1000). This is especially bad when using Folly where every dynamic object is an unordered_map

There are other point of perf pain: A) std::string doesn't fail-fast a comparison when the lengths are different (since it doesn't do a lexicographic compare), so for longer strings that would be bad. Luckily property names are short. B) we could be allocating a lot, std::string's SSO is 15 characters, so if a property name is 15 characters or more, that will go in the heap instead of being stored in the object. FBString has a SSO of 22 I believe but we are using std::string everywhere.

We already have a vector_map adapter in xaml, which provides a map API to a vector so we can use that.

The other perf idea was memoizing property names and using that when the property name is one of the known ones (like XAML does for a lot of its codegen stuff internally).

Finally, removing unordered_maps will gain us some startup time because of the dynamic initializers not having to run (see #3964).

Start by reviewing the existing vector_map adapter in XAML and the dynamic-initializer context in #3964, then inventory the std::map, unordered_map, and std::string usage described here. Define a scoped change and measurable startup or runtime criteria before proceeding; the issue names no files, tests, or concrete completion target.