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

Slow rendering of type error messages #1558

Open
sjakobi opened this issue Nov 19, 2019 · 3 comments
Open

Slow rendering of type error messages #1558

sjakobi opened this issue Nov 19, 2019 · 3 comments
Labels
error messages Better error reporting formatting performance All the slow and inefficient things

Comments

@sjakobi
Copy link
Collaborator

sjakobi commented Nov 19, 2019

In #1496 (comment) @Gabriel439 described a case of a type error where the rendering of the type context was so slow he ended up turning it off completely (#1482).

However if you use --explain you still get the context, and have to wait.

I think there are at least two things that we can do about this:

  • Speed up prettyprinter: changesUponFlattening can be slow quchen/prettyprinter#99

  • Increase laziness in the rendered types: Right now we use snip to cut off the middle of the rendered types, keeping only the first and last 20 lines.
    I believe that if we'd limit ourselves to the first lines of the type, and use lazy Text instead of strict Text, we might be able to avoid rendering the full document.

@sjakobi sjakobi added performance All the slow and inefficient things error messages Better error reporting labels Nov 19, 2019
@sjakobi
Copy link
Collaborator Author

sjakobi commented Nov 19, 2019

Some more, less promising, ideas:

  • Replace layoutSmart with layoutPretty

  • Skip removeTrailingWhitespace for error messages

@sjakobi
Copy link
Collaborator Author

sjakobi commented Nov 19, 2019

Hmm, I believe #1556 was a bad move in the context of this issue.

While the type error previously took about 7s for me to finish rendering, it now takes about 8.7s. I believe the additional time is spent rendering the colour codes.

I can revert it if that seems like the better tradeoff.

@Gabriella439
Copy link
Collaborator

@sjakobi: It's fine because it only affects the --detailed mode. My reasoning is that users who use --detailed are willing to wait longer to get better output

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error messages Better error reporting formatting performance All the slow and inefficient things
Projects
None yet
Development

No branches or pull requests

2 participants