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

Takes a very long time if run with bundle exec #64

Closed
cschramm opened this issue Apr 18, 2013 · 3 comments
Closed

Takes a very long time if run with bundle exec #64

cschramm opened this issue Apr 18, 2013 · 3 comments

Comments

@cschramm
Copy link
Contributor

Running bundle exec rubocop is a magnitude slower than running rubocop for me.

I'm not sure where this might come from, but I do not experience it with other commands like cane, rails_best_practices or brakeman.

cane 0,34s user 0,01s system 93% cpu 0,378 total
bundle exec cane 1,25s user 0,04s system 99% cpu 1,295 total
rubocop 2,78s user 0,87s system 94% cpu 3,868 total
bundle exec rubocop 95,85s user 3,80s system 99% cpu 1:40,10 total

Is it just me or can you confirm this?

@bbatsov
Copy link
Collaborator

bbatsov commented Apr 19, 2013

Yep, I can confirm this. My preliminary analysis shows that the syntax check is problematic - it starts the ruby interpreter with -wc which is pretty fast without bundler, but terribly slow with it.

bbatsov pushed a commit that referenced this issue Apr 19, 2013
For some reason running `bundle exec rubocop`
slows down the start of the ruby interpreter (used with `-wc`)
tenfold. Until we figure what's causing this slowdown it's best
not to run syntax checks if we detect bundler's presence. See #64 for
more details.
@bbatsov
Copy link
Collaborator

bbatsov commented Apr 19, 2013

Ok, it took me a while, but I've managed to fix the problem. I guess I'll release a new RuboCop over the weekend.

@cschramm
Copy link
Contributor Author

Great! 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants