-
Notifications
You must be signed in to change notification settings - Fork 25
Description
Hello there!
I enjoyed your talk at the Amsterdam Elixir meetup, and decided to give TypeCheck a try on our codebase. We have a few structs with a relatively large number of fields, and their old @type t
definitions fully specified each field. Upon changing these to @type!
and implementing a few @spec!
s on functions that used them, we quickly found that our compilation time rose to 3–4 minutes.
For reference, the rough setup is:
A.t() :: %A{...[16 fields]...}
B.t() :: %B{...[8 fields]...}
C.t() :: %B{a: A.t(), b: B.t()}
With six function specifications on module C
that reference all three types in various combinations.
So, the question: is this expected? I can imagine that the sheer number of fields on each struct, especially when nested, creates an explosion of code generation. In the documentation you mention:
In the case of for instance a large collection or a deeply-nested 'tree of structs' [runtime checks] might still be too slow.
Could this be true for compile time as well?
More generally, do you have any recommendations on strategies for type-checking structs? Perhaps the full specification of each field would make sense on a constructor function, but the canonical t
type should stop at %__MODULE__{}
with no fields.
Thanks for your work! Excited for more people to see it at ElixirConf EU.