While investigating an unrelated binary size regression ( crbug.com/714841 ) I noticed that the AccessibilityEnumMap constructor in content\browser\accessibility\accessibility_tree_formatter_utils_win.cc was quite large - about 13-14 KB. When inspecting the code I noticed that it adds ~230 int/std::string16 pairs to std::maps which means that it does about 460 memory allocations.

I think that the code size could be drastically reduced by having a static array of int/L"" pairs, and then having a loop that adds this data to the associative arrays. That is, instead of the current ~230 calls to std::map::operator= it could be reduced to  five, or perhaps just one.

The number of allocations is also a concern. Currently each entry allocates a std::map node and also allocates (unless the small-string optimization applies) memory for the string stored in the base::string16 object. Half of the allocations can easily be avoided by using base::StringPiece16 instead of base::string16. I made a proof-of-concept change that does this, uploaded to crrev.com/2864773002. The remaining allocations could be avoided by using flat_map instead of map, which also gives faster lookups.

These two techniques could be combined.

Alternately, the static array of int/L"" pairs could be used directly. This would just require sorting it in the constructor and doing a binary search over the array. With a helper function this would add essentially no additional complexity, although it would mean that the static array of int/L"" pairs could not be const.

The ultimate version would be to have the static array of int/L"" pairs be initialized in sorted order, thus getting the absolute minimum constructor size and data size, while still giving faster lookups than the current std::map solution.

For the last two solutions it might be better to have int/StringPiece16 pairs.