When use byebug and continue once, Ruby process get slow.

[kntmrkm]

After use byebug and continue.
Page load time get slow. Webrick's ruby process got slow maybe.

Before use byebug

After use

Gemfile is just

source 'https://rubygems.org'

gem 'pry-rails'

group :development do
  gem 'rack-mini-profiler'
end

group :test do
  gem 'sqlite3'
end

group :development, :test do
  gem 'pry-byebug'
end

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.2.1'
gem 'pg'
gem 'sass-rails', '~> 5.0'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.1.0'
gem 'jquery-rails'
gem 'turbolinks'
gem 'jbuilder', '~> 2.0'
gem 'sdoc', '~> 0.4.0', group: :doc

group :development, :test do
  gem 'byebug'
  gem 'web-console', '~> 2.0'
  #gem 'spring'
end

I've open issue at pry-byebug, but This relate to byebug maybe.
This is linked this issue.

deivid-rodriguez/pry-byebug#61 (comment)

[deivid-rodriguez]

@kntmrkm Cool, thanks.

I had an idea on how to improve this. I'll disable the debugger when user hits continue and there's no enabled breakpoints. I'll let you know when I get to it, or you can give it a try if you want. 😄

[jhirbour]

We're also experiencing this issue. We are using puma, but otherwise basically the same setup and symptom.

[choltz-i4cp]

Same problem here. Page load time increase substantially after debugger is hit. If I remove the byebug call from the code and refresh the page, it still runs slow. Only way to resolve is to stop and restart rails.

[kirichkov]

I've also been seeing the behavior described by @choltz-i4cp . I've tried byebug 3.1.2, 4.0.5 and even 5.0 but the bug is present in all of these versions.

[why-el]

Yep, same for me. The only remedy is a full server restart.

[stefankroes]

Same issue

[eidge]

+1

[blqke]

+1

[deivid-rodriguez]

Ignoring this thread until I get to it.

[why-el]

@deivid-rodriguez perhaps you share your idea? You said earlier "I had an idea on how to improve this", so perhaps one of us can work off of that idea and speed up a solution for this issue.

[deivid-rodriguez]

Already did, read the next sentence after the one you quoted.

[why-el]

Ah gotcha. I interpreted that as a workaround until you get to your idea. Thanks for the pointer.

[deivid-rodriguez]

👍

[ozzyaaron]

This is due to the Puma worker process (even if workers are disabled) and I've linked a previous discussion. It may be that the debugger is leaving content in the STDIN buffer or something as there was recently a fix added to Puma to try to remedy this situation. If you look at your startup log and the processes you'll see the worker hit ~ 100% CPU.

[choltz-i4cp]

The issue is not isolated to Puma. I've seen it on thin and webrick as well.

[deivid-rodriguez]

Yes, this has nothing to do with Puma. It's an issue withbyebug. It doesn't come as a surprise: byebug hooks into every single instruction run by the Ruby interpreter and even though it is C code that gets run, it doesn't come for free. We can do better though by disabling the debugger when the user does not expect it to stop anymore.

[ozzyaaron]

Oh right, no problems :)

We just were not seeing this on Unicorn or the standard Rails console, only with Puma.

[kntmrkm]

version 6.0 resolved this problem.
It's very comfortable.
Thanks a lot.

[naw]

deivid-rodriguez/pry-byebug#61 is still unresolved until pry-byebug depends on byebug 6

[deivid-rodriguez]

😮 There has not been any (intentional) fixes regarding this issue in this release...

[deivid-rodriguez]

@naw The work to support byebug 6 is already done here: https://github.com/deivid-rodriguez/pry-byebug/tree/support_latest_byebug

[naw]

OK I forked here: https://github.com/naw/pry-byebug/tree/support_latest_byebug and pointed my app at it.

Request initially around 1800ms, but after a single binding.pry call, the subsequent requests take 10x longer.

So, I'm afraid I'll have to disagree with @kntmrkm regarding whether this issue is resolved, at least when using pry-byebug

[johnnaegle]

Also not fixed for me with 6.0

# Server start, and first load of the page
Completed 200 OK in 2367ms (Views: 1305.0ms | ActiveRecord: 43.8ms)

# 4 loads of the same page, with a single new line added or removed where I'll later add a debugger statement
# Average: 918 ms
Completed 200 OK in 938ms (Views: 888.9ms | ActiveRecord: 11.9ms)
Completed 200 OK in 990ms (Views: 897.4ms | ActiveRecord: 28.0ms)
Completed 200 OK in 936ms (Views: 879.2ms | ActiveRecord: 12.9ms)
Completed 200 OK in 808ms (Views: 755.5ms | ActiveRecord: 11.8ms)


# Add the debugger statement
[1, 10] in app/views/users/new.html.haml
    1: - title "Register Today"
    2: 
    3: - debugger

# This load is okay, its the one where the debugger was hit
Completed 200 OK in 24202ms (Views: 23861.3ms | ActiveRecord: 53.6ms)

# Remove the debugger statement
# add/remove the single newline where the debugger statement was before and load the page again
# Average: 13994ms
Completed 200 OK in 13580ms (Views: 12813.4ms | ActiveRecord: 198.9ms)
Completed 200 OK in 13816ms (Views: 13021.8ms | ActiveRecord: 204.3ms)
Completed 200 OK in 13871ms (Views: 13053.0ms | ActiveRecord: 205.7ms)
Completed 200 OK in 14709ms (Views: 13875.4ms | ActiveRecord: 191.9ms)

If I go back to byebug 3.5.1 (what I used before upgrading to 5 and then 6), I still have this problem but it isn't quite as bad

# server start
Completed 200 OK in 2474ms (Views: 1308.3ms | ActiveRecord: 44.1ms)

# 4 page loads
Completed 200 OK in 716ms (Views: 660.6ms | ActiveRecord: 13.4ms)
Completed 200 OK in 723ms (Views: 677.6ms | ActiveRecord: 10.7ms)
Completed 200 OK in 711ms (Views: 645.0ms | ActiveRecord: 11.5ms)
Completed 200 OK in 712ms (Views: 616.8ms | ActiveRecord: 11.5ms)


# debugger
[1, 10] in app/views/users/new.html.haml
    1: - title "Register Today"
    2: 
    3: - debugger
Completed 200 OK in 11988ms (Views: 11904.5ms | ActiveRecord: 27.2ms)

# debugger removed, 3 page loads, much slower than before
Completed 200 OK in 5419ms (Views: 5126.6ms | ActiveRecord: 76.1ms)
Completed 200 OK in 5534ms (Views: 5232.5ms | ActiveRecord: 70.9ms)
Completed 200 OK in 5649ms (Views: 5338.9ms | ActiveRecord: 80.6ms)

Ruby 2.2.0p0, x86_64-darwin-14

[deivid-rodriguez]

The comparison to 3.5.1 is interesting and worth investigating. I'll keep that in mind when I get to this issue.

[JacksonGariety]

@deivid-rodriguez any fix for this?

[fbernier]

@JacksonGariety fixed on #160 a while ago:

[JacksonGariety]

@fbernier thanks but this still seems to be an issue on 9.0.3

[deivid-rodriguez]

@JacksonGariety Can you share some numbers? This issue seems closed for most people...

[rachitpant]

Can confirm this is an issue. I use byebug + sublime debugger and they work super slow.

[JacksonGariety]

@deivid-rodriguez rails says 1644ms prior to using binding.pry and 9816ms after executing exit/continue. We just removed pry-byebug and use them separately now.

[slhck]

Running Byebug 9.0.6 on Rails 5.0.0.1 (Ruby 2.3.0p0), and as soon as I enable it, my page load times increase dramatically. Before:

12:50:53 log.1  | Started GET "/ext_users/1/video_sessions" for 127.0.0.1 at 2016-10-27 12:50:53 
12:50:53 log.1  | Completed 200 OK in 184ms (Views: 103.5ms | ActiveRecord: 6.1ms)

After:

12:49:51 log.1  | Started GET "/ext_users/1/video_sessions" for 127.0.0.1 at 2016-10-27 12:49:51 +0200
12:50:00 log.1  | Completed 200 OK in 3478ms (Views: 2097.6ms | ActiveRecord: 106.8ms)

I'm not using any byebug statements in the code.

[deivid-rodriguez]

How do you enable the debugger without using the byebug statement? Are you running the whole server through the byebug script?

[slhck]

Ah, I should've mentioned. I'm using this initializer for remote debugging while using Unicorn as an application server:

if Rails.env.development?
  require 'byebug/core'
  Byebug.start_server 'localhost', 3001
end

I'm not sure if I've missed anything obvious… is there another way to make Byebug work with other app servers other than remote debugging like this?

[deivid-rodriguez]

Nope, it's ok. So I guess that's it, this was fixed for local debugging but probably not for remote debugging.

[printercu]

@deivid-rodriguez Found this issue and so happy that solution works for me 😃
Though I've been using new versions of gem I've been still facing the issue. The problem was in that I use ctrl-d instead of continue. Can this be fixed somehow or is it a better practice to use continue?

UPD I use debbie gem (made from jazz_hands) and it doesn't require bry-byebug explicitly. So pry-byebug gets loaded with pry's plugin mechanism, and lib/pry-byebug/control_d_handler.rb is not required at all.

[printercu]

Also seems like disable-pry doesn't stop debugger.

[Vanuan]

Any workaround for remote debugging?

[deivid-rodriguez]

Closing again in favor of #302.

[trcarden]

This still exists with local development using byebug (9.0.6) and simple byebug command

Before

Completed 200 OK in 171ms (Views: 165.0ms | ActiveRecord: 0.9ms)

After

Completed 200 OK in 8468ms (Views: 6950.9ms | ActiveRecord: 291.8ms)

[jmyers0022]

This is happening for me locally using rails 5.1.4 and byebug 9.1.0. I built a fresh app just to test it out and make sure I wasn't going crazy and was still getting the same results.

Test App (Fresh with one view and controller action):

• Before: Completed 200 OK in 14ms (Views: 11.6ms)
• After: Completed 200 OK in 339ms (Views: 316.2ms)

Real App (API call returning JSON):

• Before: Completed 200 OK in 217ms (Views: 2.2ms | ActiveRecord: 4.7ms)
• After: Completed 200 OK in 22563ms (Views: 148.7ms | ActiveRecord: 90.1ms)

Restarting the server is the only way I can remedy it. I ended up going back to pry-rails and it's not having the same issues.

[deivid-rodriguez]

Hi @trcarden and @jmyers0022, can you help me out reproducing your problems? I tried the following. Add a byebug call on a controller action, reload, type continue and the byebug prompt, remove the byebug call, reload. The server is back to fast as expected.

Can you tell me the exact steps you take to experience this issue?

[nicozhang]

same problem and I am trying to find out the reason.
My env is ruby 2.3.0 and rails5.0.0 on Mac pro. When I am trying to test the function in model, byebug will be set as a breakpoint to see how the function works.
When the process stop at the byebug, the cpu begin to raise to almost 100%, even though I continue the process. At least two processes will reach 100%.( I do not know exactly how the rails run)
Mac terminal can record some sample of the running process. I read the sample and find that the thread_pool was running crazy seems some dead lock lead to this situation. In my opinion, this problem is caused by ruby thread mechanism.

[benebrice]

I have the same issue with version 11.1.3. It's even worse when debugging a middleware. I was not able to find the root cause if this.
The only solution I got at this point is to kill Docker processes (all of them) and restart. Sometimes it's working, sometimes not. 🤷🏻‍♂️