12 ms·

Is rustfmt fast enough to reasonable be put on a save hook?

steveklabnik 9y ago
I went into one of my projects and did a `cargo fmt`, took 2.2 seconds. Dunno if that's within your tolerances or not. I personally have CI check it, rather than on save.
- wldcordeiro 9y ago
  commit or push hook is nice in my opinion. Seems like a middle ground to on save and in CI.
- XR0CSWV3h3kZWg 9y ago
  Hmm I assume that cargo fmt does it on all the files, When I wrote a lot of go I had gofmt on the write hook of my editor. It was fast enough for single files that there was never a problem. 2.2 seconds sounds rough, but if that's for lots of files it's not too much of a worry.
- RX14 9y ago
  I know it's fairly pointless performance bashing but I just couldn't stop myself :) # In the crystal-lang/crystal repo $ find . -name '*.cr' -print0 | wc -l --files0-from=- | tail -n 1 252745 total $ time bin/crystal tool format Using compiled compiler at `.build/crystal' bin/crystal tool format 0.62s user 0.04s system 106% cpu 0.625 total and only 48ms to formal the longest file in crystal (the parser)! Performance makes little practical difference as long as formatting a single file is fast enough to be on-save, but it does highlight the very interesting way that the crystal formatter is implemented. I'm not sure how rustfmt is implemented but crystal's formatter parses the file into the AST, and then does a single visitor pass of the file, in order, with a lexer in tow. It then basically reconstructs the entire file from scratch using the data both from the AST and the lexer (the AST visitor pass and lexer position have to be kept in sync). And surprisingly enough, this doesn't even make the formatter "too strict" in the way that it wipes out all existing style information as one would expect. It's a really cool - if a little messy - tool and one of I think my favorite parts of crystal (it doesn't have any config options either).
epage 9y ago
I've had it as a save hook and never noticed a slow down from it.
brobinson 9y ago
Been using it as a save hook in vscode (with RLS, too)... never noticed any slowdown because of it. The bug where it _refuses to run_ if lines are > 100 chars is annoying
- saghm 9y ago
  I've been running the nightly version with "error_on_line_overflow = false" and it's been a fairly smooth ride. It's worth mentioning that I also haven't seen it fail to format a line within 100 characters since switching to the nightly version a month or so back. https://github.com/rust-lang-nursery/rustfmt/blob/master/Configurations.md#error_on_line_overflow https://github.com/rust-lang-nursery/rustfmt/blob/master/Con...
  - brobinson 9y ago
    Yeah, I am also using nightly and manually making my lines < 100 characters so they can be formatted. It works, but it's a little annoying. :)

I went into one of my projects and did a `cargo fmt`, took 2.2 seconds. Dunno if that's within your tolerances or not. I personally have CI check it, rather than on save.

wldcordeiro 9y ago
commit or push hook is nice in my opinion. Seems like a middle ground to on save and in CI.
XR0CSWV3h3kZWg 9y ago
Hmm I assume that cargo fmt does it on all the files, When I wrote a lot of go I had gofmt on the write hook of my editor. It was fast enough for single files that there was never a problem. 2.2 seconds sounds rough, but if that's for lots of files it's not too much of a worry.
RX14 9y ago
I know it's fairly pointless performance bashing but I just couldn't stop myself :) # In the crystal-lang/crystal repo $ find . -name '*.cr' -print0 | wc -l --files0-from=- | tail -n 1 252745 total $ time bin/crystal tool format Using compiled compiler at `.build/crystal' bin/crystal tool format 0.62s user 0.04s system 106% cpu 0.625 total and only 48ms to formal the longest file in crystal (the parser)! Performance makes little practical difference as long as formatting a single file is fast enough to be on-save, but it does highlight the very interesting way that the crystal formatter is implemented. I'm not sure how rustfmt is implemented but crystal's formatter parses the file into the AST, and then does a single visitor pass of the file, in order, with a lexer in tow. It then basically reconstructs the entire file from scratch using the data both from the AST and the lexer (the AST visitor pass and lexer position have to be kept in sync). And surprisingly enough, this doesn't even make the formatter "too strict" in the way that it wipes out all existing style information as one would expect. It's a really cool - if a little messy - tool and one of I think my favorite parts of crystal (it doesn't have any config options either).

epage 9y ago

I've had it as a save hook and never noticed a slow down from it.

brobinson 9y ago

Been using it as a save hook in vscode (with RLS, too)... never noticed any slowdown because of it. The bug where it _refuses to run_ if lines are > 100 chars is annoying

saghm 9y ago
I've been running the nightly version with "error_on_line_overflow = false" and it's been a fairly smooth ride. It's worth mentioning that I also haven't seen it fail to format a line within 100 characters since switching to the nightly version a month or so back. https://github.com/rust-lang-nursery/rustfmt/blob/master/Configurations.md#error_on_line_overflow https://github.com/rust-lang-nursery/rustfmt/blob/master/Con...
- brobinson 9y ago
  Yeah, I am also using nightly and manually making my lines < 100 characters so they can be formatted. It works, but it's a little annoying. :)