CPU spikes during rails process buffer completion

[jsimpson]

Hello! I'm using Doom Emacs, with Emacs version 28.1, on an M1 MacBook Pro. I have the ruby and rails modules enabled. I'm working with a large legacy project and I am seeing very high CPU spikes on the ruby process that is spawned by robe-start.

If I toggle the buffer open and start typing anything that has hits on autocomplete, Emacs lags up and the CPU utilization of the process spikes to 100%. I can C-g C-g C-g out.

Completion inside of the emacs buffers is fine, it's only the rails process buffer which experiences this issue.

This is the process that I see on my machine: ~/.rbenv/versions/2.7.2/bin/ruby bin/rails console -e development -- --nomultiline --noreadline.

[dgutov]

Hi!

There have been a few reports like this over the years. I fixed one in #105, but #127 didn't reach any conclusion.

Could you try obtaining more info on your side using recommendations that I gave in #127?

[dgutov]

If the freezes are only inside the rails process buffer, it's likely to be something else rather than Robe, though.

Are you using Pry or plain IRB there?

[jsimpson]

I also started to suspect, after I had created this issue, that it wasn't coming from robe but is instead something inside of inf-ruby. I did see those other issues, also after the fact.

I am using Pry. FWIW, I thought to try setting Pry.config.completer = nil if ENV["INSIDE_EMACS"] in my ~/.pryrc. I could verify that the completer was in fact set to nil but it was still running the proc from inf-ruby and trying to gather completions, freezing up Emacs and spiking the external ruby process to 100% CPU utilization. C-g C-g C-g does unfreeze Emacs.

I'll collect more information for you today and add a new reply once I've gathered it all up.

[jsimpson]

rbspy:

<main> - /Users/<redacted>/projects/<redacted>/bin/rails:4
require [c function] - (unknown):0
<top (required)> - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/railties-6.1.6/lib/rails/commands.rb:18
invoke - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/railties-6.1.6/lib/rails/command.rb:54
perform - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/railties-6.1.6/lib/rails/command/base.rb:70
dispatch - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor.rb:393
invoke_command - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:129
run - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:37
perform - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/railties-6.1.6/lib/rails/commands/console/console_command.rb:103
start - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/railties-6.1.6/lib/rails/commands/console/console_command.rb:20
start - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/railties-6.1.6/lib/rails/commands/console/console_command.rb:71
start_with_pry_byebug - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-byebug-3.9.0/lib/pry-byebug/pry_ext.rb:15
start - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/pry_class.rb:195
start - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:16
start - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:41
with_ownership - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/input_lock.rb:79
__with_ownership - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/input_lock.rb:73
block in start - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:38
repl - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:80
loop [c function] - (unknown):0
block in repl - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:79
read - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:122
read_line - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:194
handle_read_errors - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:165
block in read_line - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:193
input_readline - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:200
interruptible_region - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/input_lock.rb:127
block in input_readline - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/pry-0.13.1/lib/pry/repl.rb:199
readline - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/readline.rb:58
readline - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:4883
readline_internal - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:4855
readline_internal_charloop - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:4793
_rl_internal_char_cleanup - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:4738
rl_redisplay - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:3811
update_line - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:3169
_rl_find_next_mbchar - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:8705
_rl_adjust_point - /Users/<redacted>/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:8672
(unknown) [c function] - (unknown):0

I sent a SIGUSR2 kill signal to the process, as well, and it did take it down but I don't see a backtrace buffer anywhere in my Emacs. I'm fairly new to Emacs, having switched over from vim/neovim in the last 6 months, but I'm keen to help you chase this down as far as I can.

Also, FWIW, I am using Emacs 28.1 with Doom Emacs and Robe version 0.8.3.

[dgutov]

Hmm, so you're using Pry 0.13.1 and Ruby 2.7.2.

I fixed a similar performance problem with too many modules before: https://github.com/pry/pry/pull/1588 (Pry 0.11) and https://github.com/ruby/ruby/commit/583d903c2ba5de82bd3eb2eb687b1c107938f9e2 (Ruby 2.6). Both of your versions seem higher.

And working with the Pry completer has likely seen more testing, so everything should work fine (and probably better) without you setting Pry.config.completer = nil.

From the backtrace, it seems likely that the time is actually spent inside .rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:867 which calls some C function. First of all, rb-readline is a gem one would use when the "native" readline is not available. And since it's a Ruby reimplementation, it might lead to slower performance in certain cases.

Could you try removing rb-readline from the project? You might have to recompile your Ruby with libreadline support.

[dgutov]

The SIGUSR2 advice was about obtaining a backtrace inside Emacs, whereas the delay seems to occur in Ruby process here.

[jsimpson]

Could you try removing rb-readline from the project? You might have to recompile your Ruby with libreadline support.

That seems to have done it! I really appreciate your help, thanks so much!