Interestingly, this change (or rather, https://gitlab.mpi-sws.org/FP/iris-coq/compare/a2dab2fb4959...a4731f4c73b5) made atomic_heap.v and par.v almost double their compile time:

https://coq-speed.mpi-sws.org/d/Ne7jkX6kk/coq-speed?orgId=1&from=1529316366080&to=1529324554450&var-metric=time&var-project=iris&var-branch=gen_proofmode&var-config=coq-8.8.0&var-group=(.*)

Zooming out shows that this is consistent and not just noise.

However, heap_lang/lifting.v (which uses IntoVal much more often!) is unaffected. What?!?

Cc @robbertkrebbers

And here is why:

Time rewrite /IntoVal; iIntros (<-). (* Finished transaction in 0.001 secs *)
Undo.
Time iIntros (<-). (* Finished transaction in 2.085 secs *)

In the case of par, we are basically performing a rewrite on:

IntoVal e (f1,f2)

this thing is not directly an equality, so Coq's rewrite (which is used by the <- introduction pattern) somehow first tries to see if it can use this thing as a setoid relation.

If you enable Typeclasses eauto := debug, so see its awful attempt.

IMHO, let's revert this whole change. The mount of porting it took to adapt existing developments was also not really worth the effort.

Here's the slow TC trace: https://gitlab.mpi-sws.org/snippets/173

The fast one doesn't even trigger TC search.

The mount of porting it took to adapt existing developments was also not really worth the effort.

Except that that work is already done.

Except that that work is already done.

There are surely developments by other people that have not been ported.

The fast one doesn't even trigger TC search.

The problem is, I think, that only IntoVal e (f1,f2) can be turned into a relation on the same type, namely λ v1 v2, IntoVal e (v1, v2), whereas for the others, that is not the case.

IntoVal doesn't even appear in that TC trace so I am wondering what the heck it is doing.

The problem is, I think, that only IntoVal e (f1,f2) can be turned into a relation on the same type, namely λ v1 v2, IntoVal e (v1, v2), whereas for the others, that is not the case.

I don't think so, atomic_heap also got slower and it only uses IntoVal e v.

On the other hand, it is looking for something about rtc?!???

4.1-1.2-2.1-1.1-3.1-2 : (subrelation (bi_entails ==> bi_entails)%signature
                           (rtc ?Goal0 --> flip ?r)%signature)

EDIT: Ah, here

Debug: 1.1-1.3-1.1-1.1-1 : (Reflexive ?r)
Debug: 1.1-1.3-1.1-1.1-1: looking for (Reflexive ?r) with backtracking
Debug: 1.1-1.3-1.1-1.1-1.1: simple apply @rtc_reflexive on (Reflexive ?r), 0 subgoal(s)

Should Reflexive have a Hint Mode?

After adding

Hint Mode Reflexive ! ! : typeclass_instances.

The time is down from 2s to 0.4s.

Ouch, but there is a use of setoid_rewrite which fails with that mode. Wtf.

EDIT: That setoid_rewrite indeed uses rtc for some intermediate result... that's probably discarded again later. That doesn't seem right.

Interestingly,

Remove Hints rtc_reflexive : typeclass_instances.

also reduces the time to 0.4s. It then picks iff_reflexive instead which doesn't introduce a new evar, which seems to help. It may be worth reducing the priority of rtc_reflexive, not just for this case.

https://gitlab.mpi-sws.org/robbertkrebbers/coq-stdpp/merge_requests/38 decreased the time the rewrite takes from 2s to 0.38s.

Good to hear this had an effect, but IMHO these rewrites should take something much closer to 0.