Open yakra opened 2 years ago
Interesting -- https://www.youtube.com/watch?v=M2fKMP47slQ suggests that for small containers, std::map is faster than std::unordered_map. See also https://stackoverflow.com/questions/2196995/is-there-any-advantage-of-using-map-over-unordered-map-in-case-of-trivial-keys/39864767#39864767
^ TravelerList: unordered_map -> map
CompStatsT
: faster with -O3
but not -O0
.
CompStatsR
changes.Variables & their affected tasks:
std::map<Region*, double> active_preview_mileage_by_region;
std::map<Region*, double> active_only_mileage_by_region;
std::map<HighwaySystem*, std::map<Region*, double>> system_region_mileages;
Looking at DBFieldLength.h for #119, I starting looking into when to use constexpr, which led me here, then here.
Reminded me that a lot of the time I compare the result of
std::unordered_map::find
tostd::unordered_map::end
ignore it when I could be saving it to a variable, and then waste time doing a lookup again later, usually withstd::unordered_map::at
.That article led me to this video. Neato. I'd noticed the behavior the presenter describes, but avoided it due to the same "newbie" expectations he cites, of uninitialized rather than value-initialized
double
s. Thought it was possible that not every C++ compiler would gimme the results I was seeing. Great news. This could mean good things forcompute_stats_t
. Finally, the first of these two StackOverflow threads leads right back to Louis Brandy's video.There are several ways to better use
std::unordered map
:catch
Consider using
std::unordered_map::find
, comparing tostd::unordered_map::end
and dereferencing the result instead of (potentially expensively?) constructingstd::out_of_range
objects.[] +=
[] +=
count
Consider using
std::unordered_map::find
and dereferencing the result instead of discarding it and searching again withstd::unordered_map::at
or whatever All there is right now, at least in the master branch, is 9e2e4ef.active_only_mileage_by_region.find(region)
as an iteratorsystem_region_miles
works (and all occurrences) -- does/can it just return 0?all occurrences
[]
may be accompanied by other unnecessary operations.find
cases can often have results saved in a variableinsert
andemplace
may benefit from better use of their respective construction methods; try piecewise-construct ...and whatever else