You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I investigated the problem a bit and found out that serializing those objects involves a lot of comparisons which increment the heartbeat counter. In particular, a lot of time is spent comparing deep expressions for BinderInfo-aware equality; the expression hash used in the comparison does not include BinderInfo data, and the above example seems to involve expressions which all have the same hash despite being different for the purposes of is_bi_equal.
Since there are only two comparison modes, a possible fix would be to have two hashes, one for each choice of CompareBinderInfo. I can't tell if this is worth the extra time and memory.
(Note: The above example may hit #748 on a debug build. Those issues may or may not be related.)
Steps to Reproduce
Run lean --make -T100000 test.lean on the above file
We are currently experiencing timeouts when saving some oleans (leanprover-community/lean#749). Since Lean does not error out when deterministic timeouts happen during olean generation (leanprover-community/lean#750) and we already run Lean twice when compiling mathlib, Ben Toner suggested the following clever hack: Increase the timeout, but only on the second lean run. This effectively means anything that was reported as a timeout before is still reported as a timeout (by the first call), while olean generation gets more heartbeats.
Co-authored-by: Ben Toner <bentoner@bentoner.com>
Prerequisites
or feature requests.
Description
@digama0's testcase from https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/.22saving.20olean.22.3F, reproduced below, fails to produce oleans with
lean --make -T100000 test.lean
:I investigated the problem a bit and found out that serializing those objects involves a lot of comparisons which increment the heartbeat counter. In particular, a lot of time is spent comparing deep expressions for BinderInfo-aware equality; the expression hash used in the comparison does not include BinderInfo data, and the above example seems to involve expressions which all have the same hash despite being different for the purposes of
is_bi_equal
.Since there are only two comparison modes, a possible fix would be to have two hashes, one for each choice of
CompareBinderInfo
. I can't tell if this is worth the extra time and memory.(Note: The above example may hit #748 on a debug build. Those issues may or may not be related.)
Steps to Reproduce
lean --make -T100000 test.lean
on the above fileExpected behavior: Valid oleans should be output
Actual behavior: Empty oleans
Reproduces how often: 100%
Versions
Lean (version 3.45.0, commit 22b09be, Release)
The text was updated successfully, but these errors were encountered: