Closed trws closed 4 months ago
I think the answer to that is no, because we still have to defensively check to make sure we only take the out-edges that match the subsystem we're currently exploring. This way we don't do it twice. If it turns out that it is slower though, then the solution would be to make it so we only consider the edges we want, and I would do that by changing how we store out-edges to make that efficient rather than doing this.
Attention: Patch coverage is 64.28571%
with 10 lines
in your changes missing coverage. Please review.
Project coverage is 74.1%. Comparing base (
719c692
) to head (a9b6252
). Report is 171 commits behind head on master.
The filtered_graph buys us basically nothing, but it costs order 30%-80% depending on the operation and how we measure. I need to run a performance study with and without, but for production cases it should always be a win, and it reduces compile times. It's most noticeable with the many-time-point test such that there's a ton of matches, but it should make at least a small difference everywhere.
This is stacked on top of #1224 because without it, this change made the race condition much more common and frequently hung one or more tests.
As part of routing out the filtered-graph types, I removed a number of "shared_ptr" arguments. Overall my intention is that no regular pointer type argument should ever own storage, but we can pass things by pointer when just sharing a reference to state owned by something else. Ideally these would become references, but that's more disruptive to the code.