-
Notifications
You must be signed in to change notification settings - Fork 14
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
fsep
is slow even when we don't benefit from it, relax its use?
#89
base: master
Are you sure you want to change the base?
Conversation
Allows better performance for unbounded width layouts.
What about always using |
It makes long type descriptions more readable, e.g.
But indeed I don't know whether this is ever helpful. I had attempted to preserve this behavior just in case someone was relying on it, but if you think it's unlikely, I think it'd be reasonable to just switch to |
At this point I think that Galois is the heaviest user of Another alternative would be to look at changing the underlying pretty-printing library. I think that wl-pprint might perform better here as the line wrapping logic is a bit less complicated? |
Creating as draft to have a discussion on design.
I noticed we pay a huge performance cost on running
fsep
, even though we use an unbounded width layout. I'm intending to ask upstream topretty
(alsoprettyprinter
) whether they can do anything about this, but in the meantime, it'd be nice ifllvm-pretty
was flexible enough to allow opting out offsep
in favor ofhsep
when we know there is no reason to try and "fill a line".This example PR works (and takes the pretty-printing down from ~30 seconds to ~3 seconds on my use case).
I stashed the configuration with the
LLVM
one, but this is completely unrelated. Should it warrant a second, separate implicit configuration? Or is there a nicer way of achieving this?