Skip to content

TMBitset<HGVertex*> #251

@yakra

Description

@yakra

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 a clear() 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 mvvec is nixed altogether? Is the slower iteration thru mvset (or whatever I end up calling it) outweighed by not doing all the vector's (re)allocations? Way more vertices = higher impact than nixing traveler_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.
      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 existing vector<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 of 2decc64
      • 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 extra units 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 paired Waypoint*s for regions) -- not bad!
        • Beware, lots of pitfalls
          • unit alignment, 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 a squished bool in the low bit of data, and throw? Would require replacing each use of data element with a function. PitA, probably not worth it.
          • !=: What about a larger set containing elements outside a smaller one?
            Could return 1 if start or len are 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 comparing clinched_by when compressing edges -- even no-build would work as long as I don't resize clinched_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, memcpy existing data then free it, |= in the other stuff.
          • Don't forget to clear/set the end() bit as needed.
    • We won't know how many vertices there will be when regions & systems are created, so TMBitset will need:
      • a default ctor
      • an alloc function, 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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions