Skip to content
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

Bad(?) performance on long list #3246

Open
mtzguido opened this issue Apr 14, 2024 · 0 comments
Open

Bad(?) performance on long list #3246

mtzguido opened this issue Apr 14, 2024 · 0 comments

Comments

@mtzguido
Copy link
Member

I noticed (or remembered... I think we noticed this before) that long list literals take a long time to typecheck. I looked at it and I think the root cause is solving the implicit arguments of Cons.

In a synthetic file like this:

module Slow

(* let cons (x : int) (xs : list int) : list int = Cons x xs *)
let cons (x : 'a) (xs : list 'a) : list 'a = Cons x xs

let init : list int =
    cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <|
    cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <|
    cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <| cons 1 <|
    ....

(though much longer), it takes around 20s to typecheck it. If instead we replace the definition of cons for the commented one, which just works on ints, it takes around 2s. Clearly there's an overhead to using the unifier to solve the types and instantiating the implcits, but 10x seems excessive. I think, but I didn't confirm, that the problem may come from the checking of applications not unifying the expected type as it goes through the arguments.

That is, when we check cons 1 e at expected type int, it must be the case that e <: int. But what I think happens is that we allocate a fresh ?u, check 1 against the expected type ?u, which works (with a deferred problem for int <: ?u, and then we check e against list ?u. This accumulates tons of constraints and they only get solved at the end, which probably requires much more time and memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant