Your 60% (or even 65%) figure is *seriously* understating the impact, as it's measured against a cube with only four time points. (i.e. in a circumstance where performance is almost irrelevant). The results for a larger number of time points (such as the 90000 point dataset in the discussion which led to the optimisation) paint a very different picture! e.g. 190 s vs. 0.045 s (some four thousand times slower!)

But it's worth remembering that using PartialDateTime is doing a different kind of comparison. There's no guarantee it will only match a single value in a DimCoord so the same kind of optimisation isn't even possible! So I modified the timings to do an exact "datetime" comparison (i.e. an instance of one of `PartialDateTime.known_time_implementations`):
```python
constraint = iris.Constraint(time=netcdftime.datetime(1971, 1, 2))
```
This was very nearly as bad as using the partial! :disappointed:

But all is not lost! It's possible to check for a "datetime", convert it back to a number, and then use the optimised nearest_neighbour_index path. End result: performance that's every bit as good as the numeric comparison. :tada: (It's actually a little bit faster. :smile:)

So... since we're encouraging people to switch from using numeric comparisons to date(-ish) comparisons we should definitely add this optimisation.