For the following, consider that I don’t know the code internals, so may be completely wrong (if so, please correct me).
As discussed here about wheel encoders in Rover Balance Bot (and possibly other rovers), in this issue and in this PR, in recently changed line (floating point multiplication added):
irq_state.last_reading_ms = timestamp * 1e-3f;
in this module (WheelEncoder_Quadrature.cpp), the μs to ms correction introduces additional code in a code that is going to be executed thousands of times per second (two quadrature signals per motor, at least two motors…), and I wonder if in interrupt time (and if both signal edges produce interrupt, for all quadrature signals in all encoders).
But what most surprises me is that I cannot find (grep -r in sources) any use for struct member irq_state.last_reading_ms, so it seems informative only (again: I don’t know the code).
So even not knowing the code, I think that what would be better is change the name of the struct member to irq_state.last_reading_us (WheelEncoder_Quadrature.h), and change line above to:
irq_state.last_reading_us = timestamp;
supposing that timestamp is indeed in μs.
(As appears there, I have tested the compilation and linking with this changes (but not flashed): no problems and 24 bytes saved, which is significant in a code executed thousands of times per second).
If it is only informative, for faster execution the struct member can be commented as well as that line.
Moreover, here is mentioned another possible code size reduction. There seem to be two coding alternatives in function AP_WheelEncoder_Quadrature::pin_ab_to_phase(…), and the longer one in bytes (and possibly in execution time) is chosen (perhaps the programmer has a good reason for this).
Sorry for the length: I don’t know the code internals.