use boost::unordered_flat_map for iterator cache's _object_to_iterator

[spoonincode]

I've noticed for some time that,

spring/libraries/chain/include/eosio/chain/apply_context.hpp

Lines 80 to 89 in d361a93

	int add( const T& obj ) {
	auto itr = _object_to_iterator.find( &obj );
	if( itr != _object_to_iterator.end() )
	return itr->second;
	_iterator_to_object.push_back( &obj );
	_object_to_iterator[&obj] = _iterator_to_object.size() - 1;
	return _iterator_to_object.size() - 1;
	}

shows up as taking 1.5%+ of main thread time on EOS. This function isn't doing much, and the iterator cache doesn't get large in practice. I'm not sure what is going on, but the overhead seems limited to libc++ builds (our pinned reproducible builds).

Switch the _object_to_iterator map to boost::unordered_flat_map. There is no ordering requirement for this map (either in consensus or as part of the implementation). For a replay over blocks 381452700 through 381632370, the pinned build improves by a consistent ~2%. There is no performance difference for a stdlibc++ build.

fwiw I tried a boost::container::map and it was even slower (a bit).

[heifner]

What about using std::unordered_map ?

[spoonincode]

What about using std::unordered_map ?

It might be hard to believe but std::unordered_map seems no different than std::map. My replays have a timing variance under 0.25% so seeing a consistent ~2% improvement vs no change when running over and over again makes me rather confident on it.

[greg7mdp]

It might be hard to believe but std::unordered_map seems no different than std::map

I think it makes sense, most of the time is probably spent in malloc/free (1 bucket per pair inserted in both std::map and std::unordered_map).

[ericpassmore]

Note:start
group: STABILITY
category: PERFORMANCE
summary: Improve performance of _object_to_iterator, a frequently used operation on the main thread.
Note:end