Cache layout loaded from AprilTagFields resource json
This will decrease the impact of calling AprilTagFieldLayout.loadAprilTagLayoutField() repeatedly (seen a few times on Discord/team github repos).
It will unfortunately still allocate because the origin of the field layout is mutable and could be changed by callers, so a fresh construction is needed.
Not sure the most ergonomic/idiomatic way to do this for c++; Also not sure how necessary it is (in both performance impact and likelihood of userbase to make the same mistake)
This is a pretty odd PR to me. For one, this is a breaking change, you can currently load different AprilTagLayoutField with something like a SendableChooser. After this PR you would need to restart robot code after each layout change.
It also punishes happy-path users, it forces everyone to make 2 copies of AprilTagFieldLayout.
This will decrease the impact of calling AprilTagFieldLayout.loadAprilTagLayoutField() repeatedly (seen a few times on Discord/team github repos).
I'd like to see some more discussion about what kind of mistakes you're seeing.
you can currently load different AprilTagLayoutField with something like a SendableChooser. After this PR you would need to restart robot code after each layout change
Why is this the case? This only caches built-in fields.
My bad, that is correct.
I'd like to see some more discussion about what kind of mistakes you're seeing.
Repeatedly calling AprilTagFieldLayout.loadAprilTagLayoutField() instead of calling it once and reusing the return value, leading to loop overruns and high memory utilization/GC churn.