forked from TravelMapping/DataProcessing
-
Notifications
You must be signed in to change notification settings - Fork 0
Closed
TravelMapping/DataProcessing
#622Description
Carving this out into its own issue from the OP of #245.
Nota Bene: Code examples below use old nomenclature.
TMBitset::insert is deprecated in favor of TMBitset::add_index and TMBitset::add_value, so get hip.
TMBitset<HGVertex*> simplifies code. How about performance? Don't have to zero out individual bits at least.
Create aclear()funtion, based on final selected alternative for|=operator
Or not -- current thinking is, the TMBitsets will be destroyed by exiting scope.if (vertex_set.insert(vertex)) mvvec.push_back(vertex);here and here.- Or, what if
mvvecis nixed altogether? Is the slower iteration thrumvset(or whatever I end up calling it) outweighed by not doing all the vector's (re)allocations? Way more vertices = higher impact than nixingtraveler_lists. Beware this line. (Full custom graphs only. Maybe cook up some more test cases?) Which is faster?if (!vertex_set(vw.first) && vw.second->system_match(g.systems)) { mvvec.push_back(vw.first); vertex_set.insert(vw.first); }
if (vw.second->system_match(g.systems) && vertex_set.insert(vw.first)) mvvec.push_back(vw.first);
- OTOH, better yet? This is a set! Think back to the earlier idea of unions & intersections. Avoid mucking about with iterating, checking, and adding.
- For multiregion (et al) & multisystem graphs,
|=everything together.- Get the first one via a copy ctor (thus taking care of single-region or single-system sets)
- Iterate thru any remaining and
|=them in.
- For full custom graphs, use a new
&=operator. - When a PlaceRadius is present? This may take a little more thought.
- Potential stumbling block: regions contain
std::pair<HGVertex*,Waypoint*>s.
Remember how & why; look for ways around this.
DataProcessing/siteupdate/cplusplus/classes/GraphGeneration/get_subgraph_data.cpp
Line 10 in 387c99b
if (!subgraph_contains(vw.first, threadnum) && vw.second->system_match(g->systems))
Just this. Dates to subgraph bit field (cc9da66).
With system membership done by TMBitset, no need to call system_match anymore.
Can be safely removed. - There's unused space in
HighwaySystem. Use a bool to track which systems are included in subgraphs, and only allocate for those. This can be done now to save space in the existingvector<HGVertex*>s.
RAM use figures below don't reflect this; they were calculated before I thought of it. - How much RAM for a TMBitset for each region & system?
54.22 M rg + 55.02 M sys = 109.24 M, as of2decc64- How much is saved by not allocating for devel systems or regions where
active_preview_mileage== 0?
We're down to 37.36 M rg + 53.41 M sys = 90.76 M - Consider a
TMBitset::shrink_to_fit()function (exact mechanics TBD).- What's the span, high-low+1, for each region/system? How much RAM can be saved?
We're down to 45.43 M total, for a/p systems only.
Actually a little more when accounting for potential extraunits allocated due to alignment requirements, but this should top out at 8.5 K. Negligible. :)
Compare this to 42.79 M for all vectors'capacity(including the pairedWaypoint*s for regions) -- not bad!- What if vertices are created in a different order, e.g. sys->rte->pts?
56.06 M. Weigh this against potential speed benefits noted in VISIBLE_HIDDEN_COLOC and graph_points #242's OP. - What if vertices are created in rg->rte->pts order?
- What if vertices are created in a different order, e.g. sys->rte->pts?
- Beware, lots of pitfalls
unitalignment, for memcmp and especially|=[]: Deprecate for squished applications (will vertex/edge applications just use addresses, and the()operator?) or store a new variable for orig start?
Or maybe store asquishedbool in the low bit ofdata, and throw? Would require replacing each use ofdataelement with a function. PitA, probably not worth it.!=: What about a larger set containing elements outside a smaller one?
Could return 1 ifstartorlenare unequal. OTOH, the big set could be unsquished, with everything before/after the small set's range =0.
Could just have the definition if==mean, "if the start & len and contents are equal". ;)
It's only used for comparingclinched_bywhen compressing edges -- even no-build would work as long as I don't resizeclinched_by(how much would that save?) but probably a bad idea; defies developer expectations.|=: Cope with different data ranges; start or len could differ. Find min start, max end & thus len, reallocate,memcpyexisting data thenfreeit,|=in the other stuff.- Don't forget to clear/set the
end()bit as needed.
- What's the span, high-low+1, for each region/system? How much RAM can be saved?
- How much is saved by not allocating for devel systems or regions where
- We won't know how many vertices there will be when regions & systems are created, so TMBitset will need:
- a default ctor
- an
allocfunction, a la TMArray - Member variables no longer const. Oh well.
- There's no
TMBitset::size()function, precisely because there's no efficient way to keep track of it while|=ing sets together. No big deal, as we need to iterate anyway to get the collapsed & traveled vertex counts. Just make a simple count a part of the process too.
- For multiregion (et al) & multisystem graphs,