-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf: reduce allocations in unused variable linter #2491
Conversation
|
Here are the bench results from Mathlib: http://speed.lean-fro.org/mathlib4/compare/93695581-e592-41ad-9a6a-53fe2cce9e75/to/5b225066-90b6-4cd2-94f1-9aabc1be69ef. Seems okay, saves 0.6% wall-clock, essentially all from linting. |
Scott, did you use your personal API key for the bot again? That's really confusing! |
Yes, but only while I'm testing. I put in the requests for the correct keys before I told the bot my token for today. :-) |
Nice analysis. We should point this out in the |
!bench |
Here are the benchmark results for commit 20aa03c. |
@Kha, I wonder why linting did not show as a significant change? The change is well above the 10 standard deviations (it's 85.6 stddev) and 1% threshold (it's 12.8%) in the formula. |
Unlike #2471 I do have a reason and two data points that actually back this one up! I measured the most memory allocating functions using
valgrind
'sDHAT
tool while running a recent lean nightly onstd4
's biggest file (Std/Data/List/Lemmas.lean). The DHAT viewer shows that (among other things) thisforEachExprWhere
call is responsible for a significant chunk of allocations:The initial count of total allocations was (a second run yielded almost identical numbers):
Judging from the doc-string in the implementation of
forEachExprWhere
it should only be favored overforEachExpr
if the proposition (in this caseisFVar
) doesn't hold for many subterms. However there are of course a ton of subterms that are free variables here. So I decided to try and switch this toforEachExpr
instead which yielded:on the same file, the allocation chunk also disappeared from my measurements. I furthermore measured std4 compilation time and did get a measurable speedup in:
before:
after:
I thus again request someone with privileges to give the bench run a try^^