RM7: very slow debugging process

Hi all.

After installing the latest RM debugging process takes a lot of time.

Before each breakpoint I placed IDE hangs for about 3-15 seconds. Then it displays current vars values via inline debugging. If I choose "Step over" after that it is repeated again. It is almost impossible to use such kind of debugging I think.

But I don't have any performance problems with Idea 14 installed while using inline debugging.

Any suggestions?

Thanks.

RubyMine 7
OS X 10.10.1

10 comments
Comment actions Permalink

Hi,

what ruby are you using?  Also is it possible to provide test project which demonstrates the problem for you?

Regards, Oleg.

0
Comment actions Permalink

Using old one ruby-1.9.3-p392.

I found some kind of dependencies for my situation to arise. Two Rails projects are opened in the same RM-window:

  1. Starting first application via run configuration
  2. Staring sunspot:solr:start rake task (https://github.com/sunspot/sunspot), it is running in foreground and is just starting up jetty app server
  3. Starting second application via run configuration


Then any breakpoint placed in first or second application will lead to lags I described in the first message.

But.

If I will launch the sunspot rake task after all Rails application have been started debug will go as it should!

I will try to prepare a bundle with sample project.

0
Comment actions Permalink

Hmm,  I'd check solr activity you have in the first and the second case.
I suspect slowness may be caused by some remote interaction with solr which is not triggered in the second case.

Hope this helps, Oleg.

0
Comment actions Permalink

In both cases solr receives the same request as I type identical symbols in a search field (on front-end part). So I don't actually understand how to check suspicious activity?

I plan to check behavior of RM if solr rake task will be started from outside of IDE.

0
Comment actions Permalink

Me too. I just upgraded to RM7 over the weekend and it had me install newer Gems for debugging as soon as I opened it. I'm also using Ruby 1.9.3 (p448), but I don't have two Rails projects open, and I'm not using SOLR at all to the best of my knowlege. I don't know how to check SOLR activity, but I did check the Activity Monitor and it's not CPU-bound, memory-bound, or IO-bound. However, RubyMine just seems to bind up for 15 seconds or more every time it hits a breakpoint, or when stepping through code. I tried downgrading back to RM 6.3, and while this changed the debugger behavior, it didn't really make it better. RM 6.3 displayed the stack frame right away, but hung while "Collecting Data".

If you have any information on how to downgrade RubyMine, including downgrading the Gems RM 7 updated for me, it would be much appreciated. This is a disaster for me. My productivity with Ruby has been crippled.

0
Comment actions Permalink

Hi,

you need manually uninstall ruby-debug-ide and ruby-debug-base19 after that RM 6.3 will install other versions.
As for slowness, I have a theory what may cause the problem and so I've created an experimatal branch (https://github.com/ruby-debug/ruby-debug-ide/tree/no-compact-name)
for ruby-debug-ide.  Could you please try it: add ruby-debug-ide from the branch to Gemfile (see http://bundler.io/v1.3/git.html for details) and let me know if it helps or not.

Thanks in advance, Oleg.

0
Comment actions Permalink

Hi Oleg, thanks for your reply! I haven't been successful following your advice though.

First for the experimental branch, I assume the Gemfile you mean is my Rails project Gemfile, since I don't know of any others. That didn't have the ruby-debug-ide in it before, but anyway I added this to the development section:


gem 'ruby-debug-ide', :git => 'https://github.com/ruby-debug/ruby-debug-ide/blob/no-compact-name'

bundle install then failed with the message:
fatal: repository 'https://github.com/ruby-debug/ruby-debug-ide/blob/no-compact-name/' not found.

I tried some permutations:
gem 'ruby-debug-ide', :git => 'https://github.com/ruby-debug/ruby-debug-ide/blob/no-compact-name/ruby-debug-ide.gemspec'
gem 'ruby-debug-ide', :git => 'https://github.com/ruby-debug/ruby-debug-ide/blob/no-compact-name/bin/ruby-debug-ide'
gem 'ruby-debug-ide', :git => 'https://github.com/ruby-debug/ruby-debug-ide/blob/no-compact-name/bin'
gem 'ruby-debug-ide', :git => 'https://github.com/ruby-debug/ruby-debug-ide/blob/no-compact-name/ruby-debug-ide.git'

None of these worked any better. I don't really know what I'm supposed to do.


In the meantime, could you help me understand how to manually uninstall ruby-debug-ide and ruby-debug-base19? The only place I can find any reference at all to those gems on my system is in a ruby-1.9.3-p545 subfolder, and that's not the version of Ruby I'm using. Does RubyMine have its own place to install them?

ETA: OK, I was able to downgrade to RubyMine 6.3 successfully. I switched to 545 Ruby and used rvm's gem uninstall there on those two gems, then switched back to 484 and ran the uninstall again, even though it didn't seem to do anything there. Then I restarted RM 6.3 and launched the debugger. It noticed the missing gems and reinstalled them. Things seem to be back to normal now, which is a huge relief. Thanks for your help! I'll monitor this thread though to see if I'll be able to "re"-upgrade in the future.

0
Comment actions Permalink

Hi,

to use the branch from github you can use the following command in you Gemfile:

gem 'ruby-debug-ide', github: 'ruby-debug/ruby-debug-ide', branch: 'no-compact-name'

Hope this helps, Oleg.

0
Comment actions Permalink

Oleg I tried your branch (0.4.24.beta1) and it's definitely faster than the 0.4.23 plugin although it doesn't seem to be as fast as the 6.3 plugin was.  As an aside to get the gem command working I had to completely uninstall all versions of the plugin before installing the new one.

Any chance you could officially release this so I don't need to include the gem in all my projects?

Justin

0
Comment actions Permalink

There is  a bug about this problem - RUBY-16055 hope to fix it soon.

Regards, Oleg.

0

Please sign in to leave a comment.