perf: CKF measurement selector runs after track state creation

[andiwand]

acts/Core/include/Acts/TrackFinding/CombinatorialKalmanFilter.hpp

Lines 588 to 591 in 4935604

	// Create trackstates for all source links (will be filtered later)
	// Results are stored in result => no return value
	createSourceLinkTrackStates(state.geoContext, result, boundState,
	prevTip, slBegin, slEnd);

After Acts-Athena track finding performance discussions I wondered if this might be one of the spots in our CKF where we loose CPU. For surfaces with tons of clusters we would create track states for each of them and only select the cluster afterwards.

I suppose this is done to get the calibration into place and prepare everything for the selection but I wonder if this is a reasonable overhead.

Apart from that we wondered if the calibration is strictly necessary for the selection or if we could have a loose cut without calibration and then a hard cut with calibration.

[paulgessinger]

The original idea was definitely to have the calibration done, but clearly it's not obvious that this is strictly necessary.

OTOH, the CKF reuses a single buffer for these track states, so does not need to allocate every time.

Finally, even if we smooth after the fact, that's not necessarily a complete refit, i.e. we can technically reuse at least part of the calculation that the CKF did, including calibration.

[andiwand]

Right I think this ties into the discussion of what should be compared. Since our current implementation does a complete fit we should compare it to more than just the finding step of Athena. But at this point it is not clear if the output is comparable.

[github-actions]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.