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

Spring taking minutes to run on MacOS with M1 Chip #635

Open
yv3s opened this issue Dec 8, 2020 · 6 comments
Open

Spring taking minutes to run on MacOS with M1 Chip #635

yv3s opened this issue Dec 8, 2020 · 6 comments

Comments

@yv3s
Copy link

yv3s commented Dec 8, 2020

Hi folks,

Just got the new Macbook Pro with the Apple M1 Chip.
Reinstalled everything as usual through the terminal on Rosetta to avoid issues ! Everything works perfectly except my Rails Console.
Everytime I launch it it takes literally minutes to start. After the first start, I can exit and relaunch within a sec, but the first start is always a pain.

My first guess is that it has something to do with Spring and Rosetta.

When I check on the spring server it gets stuck on

[2020-12-08 17:56:18 +0100] [60586] [application:development] preloading app

Any other similar experience ?

Best

@henryaj
Copy link

henryaj commented Dec 10, 2020

Working over here – running Ruby 2.7.1 and Rails 6.0.3.2. I am noticing Spring pegging a CPU core or two so am having to disable it.

@bumi
Copy link

bumi commented Feb 17, 2021

having similar issues, but could not debug it further.

@nhh
Copy link

nhh commented Mar 19, 2021

Same here, spring burns three cpus on apple mac m1.

=> Booting Puma
=> Rails 6.0.3.2 application starting in development 
=> Run `rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 5.2.2 (ruby 2.7.2-p137) ("Fettisdagsbulle")
*  Min threads: 5
*  Max threads: 5
*  Environment: development
*          PID: 76293
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000

Bildschirmfoto 2021-03-19 um 14 35 37

@diego-silva
Copy link

I was having a similar issue and my problem was that we were using spring-watcher-listen as suggested on https://github.com/rails/spring#watching-files-and-directories but our version of listen was outdated.

I suggest you guys take a look at that and upgrade listen to at least v3.3.0 (https://github.com/guard/listen/releases/tag/v3.3.0) as it includes a change to support Big Sur guard/listen#479.

@henryaj
Copy link

henryaj commented Mar 26, 2021

Yep, CPU issue is resolved by upgrading listen. @yv3s if that fixes things for you, do you want to close this out?

@StephenVNelson
Copy link

I was having a similar issue and my problem was that we were using spring-watcher-listen as suggested on https://github.com/rails/spring#watching-files-and-directories but our version of listen was outdated.

I suggest you guys take a look at that and upgrade listen to at least v3.3.0 (https://github.com/guard/listen/releases/tag/v3.3.0) as it includes a change to support Big Sur guard/listen#479.

spring-watcher-listen doesn't currently have a release that can handle spring 3.0 but you can access a version that does but putting this in your gemfile gem 'spring-watcher-listen', github: 'timdorr/spring-watcher-listen'

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

6 participants