-
Notifications
You must be signed in to change notification settings - Fork 898
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
rustfmt is prohibitively slow for sufficiently nested structs #5128
Comments
Here is a zip file containing the generated Prost where these structs are defined, which should help anybody repro |
I can't reproduce this locally, nor on the playground with the provided snippet. Are you sure you've provided a reproducible snippet in the issue description? I appreciate a binary attachment, but need to get to a point where the snippet in the issue description is reproducible, or if not possible (due to needing multiple files, etc.) then a repro repo is preferable over having to download and extract an arbitrary archive. Finally, most generated code skips formatting, and that's why many generators use one of our several available mechanisms to support ignoring an entire file. Obviously the latency reported is problematic, but to be fully transparent, with it being related to generated/non-human written code it's also not something I'm likely to have sufficient bandwidth to review any time soon. |
Thanks for the prompt response! Here's a compile-able playground that includes my an extended version of my snippet plus the Prost bindings. rustfmt indeed times out on this. This new snippet includes 1 function definition and then lots of struct definitions. If you delete the function but keep the struct definitions, Understandable that you may not have bandwidth to look. I was able to unblock myself by running rustfmt on my local machine (it took 12 minutes on the contents of this playground), and then slapping I also wonder whether having many different struct kinds referenced in a block would in-and-of-itself make rustfmt slower/more resource intensive while formatting the block. Or instead, would an equally nested code block be equally slow if it used 1 recursive struct repeatedly, rather than this code-generated web of different nested structs? Issue #4867 makes it seem like deep nesting causes a problem in-and-of-itself. |
It is because of |
That's really interesting @HKalbasi . I suppose I could try changing my rustfmt configuration to increase the max_width parameter and see if that makes the runtime acceptable. It seems like the I wonder if there's something else that can be done for rustfmt to be more intelligent about trying only certain possible formattings, or for the user to give a hint about how a certain block should be formatted to circumvent the exponential runtime. EDIT: Even using However, I will close my issue with the following takeaway:
If you were able to have granular configuration such as Another suggestion: Since rustfmt is really struggling to fit within the Thanks for your help! |
The following snippet is about 220 lines containing a total of 13570 characters.
Running rustfmt against this file takes an inordinately long amount of time, with the following output from
--verbose
onrustfmt 1.4.38-nightly (0fb1c371 2021-12-06)
Spent 0.020 secs in the parsing phase, and 444.417 secs in the formatting phase
This is actually only a substruct of the greater struct which I'm trying to validate. For the complete struct that I'm trying to validate, rustfmt exceeds 10 minutes of runtime, which makes it fatally time-out in my CI.
For context, these symbols come from Prost generated bindings against the
https://github.com/pganalyze/libpg_query
protobufs.Is there known to be super-linear runtime scaling w.r.t. the amount of nesting of a struct or code block? This seems to be so slow that it ought to be considered a bug.
See also: #4867
The text was updated successfully, but these errors were encountered: