Converting unordered_maps & unordered_sets to maps & sets (related: #216) can eliminate the need to sort existing containers.
Vectors can be sorted using std::sort.
Use lambdas where comparators aren't reused.
Functions:
functions=$(\
grep -h -m 1 'sort_[a-z_]*' `find . -name \*.cpp`\
| sed -e 's~.*\(sort_.*\)[()].*~\1~' -e 's~(.*~~'\
| sort | uniq)
echo -e "$functions\n"
for f in $functions; do
grep -n $f `find . -name \*.cpp`; echo
done
Regions
[x] ~Replace both Region::allregions and Region::code_hash with a std::map~
3725124 on BiggaTomato. Not going to worry about this. Made things slightly slower, absence of sorting notwithstanding.
Also yielded uglier code w/r.second everywhere. And that piecewise_construct is... verbose.
~No need to create & sort regions in allbyregionactivepreview~
~No need to create & sort regions in allbyregionactiveonly~
[ ] Replace HighwaySystem::mileage_by_region with a std::map
[ ] No need to create & sort regions in HighwaySystem::stats_csv
[ ] No need to create & sort sysregions in TravelerList::userlog
[ ] No need to create & sort regions_in_system for highwaydatastats.log in main
[ ] Replace TravelerList::active_preview_mileage_by_region with a std::map
[ ] No need to create & sort travregions in TravelerList::userlog
[ ] mark_connected_route_segments.cpp: make region_set a std::set
[ ] Performance? Where do we iterate through Region::allregions? It's a relatively small container though; impacts should be minimal. Maybe not noticeable at all.
Waypoints
[ ] Waypoint::near_miss_points can be a vector. Sort using std::sort. Will things be faster?
[ ] Will it be efficient to sort NMP lists in NmpSearchThread at this point?
[ ] WaypointQuadtree::points can be a vector. Sort using std::sort. Will things be faster?
Routes
[ ] Replace TravelerList::updated_routes with a std::set
[ ] Replace Route::sort_route_updates_oldest with a lambda
[ ] No need to create & sort route_list in TravelerList::userlog
[ ] This will move the sorting from TravelerList::userlog to TravelerList setup. How will this affect performance? FreeBSD in particular?
TravelerLists
[x] TMBitset was implemented for HighwaySegment::clinched_by in d9f0231 and the per-subgraph traveler_set in 634da8b. The TMBitsets always have their bits in the same order as (the pre-sorted) TravelerList::allusers. No sorting necessary.
Converting
unordered_maps &unordered_sets tomaps &sets (related: #216) can eliminate the need to sort existing containers. Vectors can be sorted using std::sort. Use lambdas where comparators aren't reused.Functions:
Region::allregionsandRegion::code_hashwith astd::map~3725124on BiggaTomato. Not going to worry about this. Made things slightly slower, absence of sorting notwithstanding. Also yielded uglier code w/r.secondeverywhere. And thatpiecewise_constructis... verbose.regionsinallbyregionactivepreview~regionsinallbyregionactiveonly~HighwaySystem::mileage_by_regionwith astd::mapregionsinHighwaySystem::stats_csvsysregionsinTravelerList::userlogregions_in_systemfor highwaydatastats.log inmainTravelerList::active_preview_mileage_by_regionwith astd::maptravregionsinTravelerList::userlogregion_setastd::setWaypoint::near_miss_pointscan be a vector. Sort usingstd::sort. Will things be faster?NmpSearchThreadat this point?WaypointQuadtree::pointscan be a vector. Sort usingstd::sort. Will things be faster?TravelerList::updated_routeswith astd::setRoute::sort_route_updates_oldestwith a lambdaroute_listinTravelerList::userlogTravelerList::userlogtoTravelerListsetup. How will this affect performance? FreeBSD in particular?TMBitsetwas implemented forHighwaySegment::clinched_byin d9f0231 and the per-subgraph traveler_set in 634da8b. The TMBitsets always have their bits in the same order as (the pre-sorted)TravelerList::allusers. No sorting necessary.system_region_mileages?