There are a few ways in which the current legal_moves code may not be optimal.
- For
SimplePosition, the result is created by repeatedly pushing to a Vec::new(). It would be possible to calculate the size of the vector in advance, and use Vec::with_capacity - this could avoid many reallocations of memory.
- The number of legal moves (and thus the size of the vector) could even be stored, and updated as moves are made. This would remove the need for a separate calculation.
- For
CompoundPosition, we also repeatedly push to a Vec::new(), so the above optimisation ideas apply. Also, we separately compute vectors for each constituent SimplePosition, copy the data across, and throw away the sub-vectors. This should be avoidable via some sort of lazy iteration mechanism in SimplePosition.
These ideas would need to be tested by empirical benchmarks before being adopted. I don't know up front if they would be an improvement.
There are a few ways in which the current
legal_movescode may not be optimal.SimplePosition, the result is created by repeatedlypushing to aVec::new(). It would be possible to calculate the size of the vector in advance, and useVec::with_capacity- this could avoid many reallocations of memory.CompoundPosition, we also repeatedlypushto aVec::new(), so the above optimisation ideas apply. Also, we separately compute vectors for each constituentSimplePosition, copy the data across, and throw away the sub-vectors. This should be avoidable via some sort of lazy iteration mechanism inSimplePosition.These ideas would need to be tested by empirical benchmarks before being adopted. I don't know up front if they would be an improvement.