4 ms·

Not sure it's quite the same. My understanding is that `ipython --pdb` would run the entire program in debugging mode, causing a dramatic slow-down in performan

Not sure it's quite the same. My understanding is that `ipython --pdb` would run the entire program in debugging mode, causing a dramatic slow-down in performance of the app. The approach taken by pry-rescue in contrast is to check for exceptions in a bounded portion of code (as many bounded portions as you want), so the slow-down is constrained to hot spots. This potentially makes pry-rescue OK for production use, something perhaps not suitable for ipython --pdb afaict.

gingerlime 14y ago
you're probably right, and it sounds like a nice idea to create an exception wrapper that on exception does `import ipdb; ipdb.set_trace()`. However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this is enhanced even more comparing rails to django (the stacks I used pry and ipdb with, respectively)... I guess at least tab-completion slowness is down to the fact that by its nature ruby has far many more functions that can run on any object than python, and hence more options to tab-complete?
- banister 14y ago
  hmm, weird. Aside from tab-completion what else is slow? I've never had responsiveness issues with Pry, even tab completion is snappy.
  - gingerlime 14y ago
    I actually think it's mostly rails, not pry. I'm still new to rails and ruby, but somehow it feels much slower than django. Just loading the console feels like forever compared to the django shell. However, regarding tab completion. I just did a quick test and noticed a small but important difference. Clicking tab in ipython instantly shows you the available completions. in pry, most of the time I have to click twice to see them! maybe that's what makes it feel slow to me.
    - banister 14y ago
      Possibly :) tab-completion will be substantially improved in an upcoming release :)
      - gingerlime 14y ago
        Great! looking forward to it. :)

gingerlime 14y ago

you're probably right, and it sounds like a nice idea to create an exception wrapper that on exception does `import ipdb; ipdb.set_trace()`. However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this is enhanced even more comparing rails to django (the stacks I used pry and ipdb with, respectively)... I guess at least tab-completion slowness is down to the fact that by its nature ruby has far many more functions that can run on any object than python, and hence more options to tab-complete?

banister 14y ago
hmm, weird. Aside from tab-completion what else is slow? I've never had responsiveness issues with Pry, even tab completion is snappy.
- gingerlime 14y ago
  I actually think it's mostly rails, not pry. I'm still new to rails and ruby, but somehow it feels much slower than django. Just loading the console feels like forever compared to the django shell. However, regarding tab completion. I just did a quick test and noticed a small but important difference. Clicking tab in ipython instantly shows you the available completions. in pry, most of the time I have to click twice to see them! maybe that's what makes it feel slow to me.
  - banister 14y ago
    Possibly :) tab-completion will be substantially improved in an upcoming release :)
    - gingerlime 14y ago
      Great! looking forward to it. :)