Conversation
PR summary 8277e451a7Import changes for modified filesNo significant changes to the import graph Import changes for all files
Declarations diffNo declarations were harmed in the making of this PR! 🐙 You can run this locally as follows## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>The doc-module for No changes to technical debt.You can run this locally as
|
|
My suspicion is that the |
|
I'm not sure how to fix the last sorry (and cannot benchmark without that, it seems). Do you have an idea? |
|
The problem was that in |
Oh wow. Thanks for catching and fixing this! (And I wonder if this issue also occurs in other places in mathlib... though I am not sure how to test for this.) |
|
!bench |
|
This can only happen in definitions, since theorems determine their type before elaborating the proof. And hopefully definitions get used, so that this kind of change gets caught immediately. But maybe with instances it can be less obvious when this problem arises. |
|
!bench |
|
Here are the benchmark results for commit 8277e45. Benchmark Metric Change
======================================================================================
- build aesop 20.3%
- ~Mathlib.Algebra.Category.Grp.LeftExactFunctor instructions 54.2%
- ~Mathlib.Algebra.Category.ModuleCat.Topology.Basic instructions 7.9%
- ~Mathlib.AlgebraicGeometry.Morphisms.ClosedImmersion instructions 45.6%
- ~Mathlib.AlgebraicTopology.SimplicialNerve instructions 42.1%
- ~Mathlib.AlgebraicTopology.SimplicialObject.Basic instructions 11.2%
- ~Mathlib.CategoryTheory.Comma.StructuredArrow.Basic instructions 7.2%
- ~Mathlib.CategoryTheory.Monoidal.Internal.Module instructions 27.7%
- ~Mathlib.CategoryTheory.Skeletal instructions 77.0%
- ~Mathlib.Condensed.Discrete.LocallyConstant instructions 68.3%
- ~Mathlib.Order.Category.BoolAlg instructions 48.7%
- ~Mathlib.Order.Category.FinBoolAlg instructions 60.1%
- ~Mathlib.Topology.Sheaves.SheafCondition.PairwiseIntersections instructions 16.1% |
Since mathlib includes leanprover/lean4#7448, update the comment accordingly. #25475 shows that this fast-path is still beneficial: so leave it, but update its comment accordingly.
|
It seems this optimisation is still useful: thus, let's keep this (but only update the comment). #25482 does so. |
|
The performance changes does appear small than in #21330 which introduced it: but it's still significant enough, in my opinion. |
|
By the way, does the speedcenter website work for you? when I click the |
|
I get the same error. |
|
Now the comparison page loads fine: mathlib slows down by 600*10⁹ instructions (~0.44%) --- which is about a third of the original magnitude of #21330. In other words: it's great to confirm that this change is less required, but it's still worth keeping. |
Since mathlib includes leanprover/lean4#7448, update the comment accordingly. #25475 shows that this fast-path is still beneficial: so leave it, but update its comment accordingly. Co-authored-by: grunweg <[email protected]>
Since mathlib includes leanprover/lean4#7448, update the comment accordingly. leanprover-community#25475 shows that this fast-path is still beneficial: so leave it, but update its comment accordingly. Co-authored-by: grunweg <[email protected]>
Since mathlib includes leanprover/lean4#7448, update the comment accordingly. leanprover-community#25475 shows that this fast-path is still beneficial: so leave it, but update its comment accordingly. Co-authored-by: grunweg <[email protected]>
By now, mathlib is on a Lean version including leanprover/lean4#7428 (for which #21330 was a workaround).
Let's measure the performance implications of reverting that change.