Another small optimization for forward demodulation.
Code trees index terms normalized to increase the number of shared instructions. Hence, the substitution we get from matching is for the normalized term and not the original indexed term, hence we need to renormalize to get a substitution for the original term.
If done during each query, this renormalization can consume up to a third (!) of the runtime in cases when demodulation fails a lot (mainly due to the later ordering checks).
Instead, we can normalize the term to be indexed before indexing it and tell the code tree that no renormalization is needed. I added a new leaf data DemodulatorData where we can cache all kinds of relevant bits for a particular orientation of a demodulator; and I left the code for the original leaf data intact so this shouldn't cause problems for application where code trees are used for different purposes.
There are a couple of discussion points:
Do we use type traits anywhere? I added a type trait for normalized indexed data, but not sure it fits what we have elsewhere.
Where should the normalization happen? It is now done by the caller and checked in the DemodulatorData ctor, so that no accidental "overnormalization" happens by an ignorant caller.
Should we check preorderedness/normalizedness/other demodulator properties? I placed some in DemodulatorData ctor, which should be cheap or we could skip them altogether.
Another small optimization for forward demodulation.
Code trees index terms normalized to increase the number of shared instructions. Hence, the substitution we get from matching is for the normalized term and not the original indexed term, hence we need to renormalize to get a substitution for the original term.
If done during each query, this renormalization can consume up to a third (!) of the runtime in cases when demodulation fails a lot (mainly due to the later ordering checks).
Instead, we can normalize the term to be indexed before indexing it and tell the code tree that no renormalization is needed. I added a new leaf data
DemodulatorDatawhere we can cache all kinds of relevant bits for a particular orientation of a demodulator; and I left the code for the original leaf data intact so this shouldn't cause problems for application where code trees are used for different purposes.There are a couple of discussion points:
DemodulatorDatactor, so that no accidental "overnormalization" happens by an ignorant caller.DemodulatorDatactor, which should be cheap or we could skip them altogether.