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
{{ message }}
Repository navigation
Poor compile time performance with deeply nested types #3376
I am working on a project where I represent large amounts of data at the type level using RowLists and noticed terrible (super-exponential) asymptotic compile time performance with respect the the number of elements in the list. It isn’t noticable for fewer than 8 elements, but takes ~30 minutes for a 15 element list.
Initially I thought it was an unavoidable issue with constraint solving, however after further experimentation I found that I could reproduce the slowdown with this following (invalid) program:
moduleMainwheret:: ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T )))))))))))))))))
This takes ~15 seconds on my laptop to get an error message.
(I have experience this behaviour on both versions 0.11.6 and 0.12.0)
I haven't yet investigated any further, but I'm guessing it's an issue with the parser/AST representation.
I've written a script that generates programs with increasingly nested types and plotted a graph displaying the results:
I would be happy to work on a fix, however I am very busy until the start of July.
Yep, this is indeed a problem with parseType. Another repro, this time in the repl:
$ stack repl purescript:lib
> Right toks = Language.PureScript.lex "" "T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T ( T )))))))))))))"
> runTokenParser "" parseType toks
which takes 10 seconds or so before producing any output.
This doesn't seem worth the effort of putting together a test for so I think we can close it. (come to think of it, at some point I suppose we will probably want to add performance regression tests for the compiler as a whole)
Activity
jonathanlking commentedon Jun 4, 2018
If you rewrite a nested type using type synonyms there is no performance degradation - so it looks like it's definitely an issue with the parser!
jonathanlking commentedon Jun 4, 2018
So unfortunately the
TypeSynonymInstanceerror limits the type synonym trick as a temporary workaround...jonathanlking commentedon Jun 4, 2018
I have profiled
purscompiling one of these programs, and have the profiterole output here.garyb commentedon Jun 5, 2018
Thanks for the report and investigation!
hdgarrood commentedon Feb 14, 2019
@natefaubion Your new parser would fix this, presumably?
hdgarrood commentedon Feb 14, 2019
Yep, this is indeed a problem with
parseType. Another repro, this time in the repl:which takes 10 seconds or so before producing any output.
hdgarrood commentedon Feb 14, 2019
I just checked and @natefaubion's new parser does indeed fix this.
hdgarrood commentedon May 7, 2019
This doesn't seem worth the effort of putting together a test for so I think we can close it. (come to think of it, at some point I suppose we will probably want to add performance regression tests for the compiler as a whole)