Comments (19)
Definitely seeing the same thing here. A request that took about 400ms in 1.9.3 with debug is taking about 2s with 2.0.0.
My setup is roughly the same, OS X 10.8.4 but debase 0.0.4 and ruby-debug-ide 0.4.18.
from debase.
same here....
from debase.
Guys, I've pushed 31cbdee that is approximately 2x faster on simple render action on my machine. Please try building from repo and see if that helps.
from debase.
OK so from my initial testing the new commit is definitely faster but still noticeably slower than the 1.9 debug. I tested a JSON request on ruby 1.9 debug, debase 0.0.4, and the debase from that commit and I saw results of 700ms, 1.4s, 2.2s. And on a large page load with a lot of dynamic requests (178 total requests) I saw times of 18s with ruby 1.9 debug, 41s with the new debase and 1.0m with debase 0.0.4.
from debase.
I'm trying to reuse full lazy stack evaluation using rb_debug_inspector like ko1/debugger2 does and it brings time on par with 1.9, but there are two main issues:
- Calculated vs real stack size mismatch rendering stepping unusable
- Segfault on breakpoints
from debase.
I've pushed b0aa71d resolving issue 1 and d52ec18 resolving issue 2. Please update and try again
from debase.
OK I just pulled down the latest version and it seems really fast now. I would have to do more testing but it seems faster than 1.9 debug.
However, I'm running into it restarting unicorn on breakpoint hit so I'm guessing it must be segfaulting still. I ran gdb on the unicorn process and here's what it output:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000009
[Switching to process 98390 thread 0xc07]
0x000000010ffc36a8 in context_create (thread=140247853841280, cDebugThread=140247787270720) at context.c:137
137 context->stack_size = (int)RARRAY_LEN(rb_funcall(thread, rb_intern("backtrace_locations"), 1, INT2FIX(1)));
from debase.
Can you please attach output from bt command in gdb?
from debase.
(gdb) bt
#0 0x000000010ffc36a8 in context_create (thread=140247853841280, cDebugThread=140247787270720) at context.c:137
#1 0x000000010ffc49ec in Debase_thread_context [inlined] () at /Users/odom/.rvm/gems/ruby-2.0.0-p247@focal-rails/bundler/gems/debase-b0aa71dd9d18/ext/debase_internals.c:31
#2 0x000000010ffc49ec in Debase_current_context [inlined] () at /Users/odom/.rvm/gems/ruby-2.0.0-p247@focal-rails/bundler/gems/debase-b0aa71dd9d18/ext/debase_internals.c:40
#3 0x000000010ffc49ec in process_return_event (trace_point=140247820879200, data=<value temporarily unavailable, due to optimizations>) at debase_internals.c:233
#4 0x000000010fc93a8b in tp_call_trace (tpval=140247820879200, trace_arg=<value temporarily unavailable, due to optimizations>) at vm_trace.c:935
#5 0x000000010fc95583 in exec_hooks (th=0x7f8e05950340, list=0x7f8dfa8035d0, trace_arg=0x111977980, can_clean_hooks=<value temporarily unavailable, due to optimizations>) at vm_trace.c:268
#6 0x000000010fc93096 in rb_threadptr_exec_event_hooks_orig (trace_arg=0x111977980, pop_p=1) at vm_trace.c:309
#7 0x000000010fc86d11 in vm_exec (th=<value temporarily unavailable, due to optimizations>) at vm.c:1405
#8 0x000000010fc8a433 in invoke_block_from_c (th=<value temporarily unavailable, due to optimizations>, block=0x7f8dfe0a0580, self=140247933859040, argc=0, argv=<value temporarily unavailable, due to optimizations>, blockptr=<value temporarily unavailable, due to optimizations>, cref=<value temporarily unavailable, due to optimizations>, defined_class=<value temporarily unavailable, due to optimizations>) at vm.c:648
#9 0x000000010fc855cb in vm_invoke_proc (th=0x7f8e05950340, proc=0x7f8e0591cf60, self=<value temporarily unavailable, due to optimizations>, defined_class=<value temporarily unavailable, due to optimizations>, argc=0, argv=0x7f8dff823bb8, blockptr=<value temporarily unavailable, due to optimizations>) at vm.c:696
#10 0x000000010fc85510 in rb_vm_invoke_proc [inlined] () at vm.c:715
#11 0x000000010fc85510 in rb_vm_invoke_proc [inlined] () at /Users/odom/.rvm/src/ruby-2.0.0-p247/vm.c:224
#12 0x000000010fc85510 in vm_call0_body (th=<value temporarily unavailable, due to optimizations>, ci=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at vm.c:1669
Previous frame identical to this frame (gdb could not unwind past this frame)
from debase.
It appears to something with the rb_funcall. My gdb is kind of rusty but I set a breakpoint and was stepping through and hit this line:
(gdb) next
rb_funcall (recv=<value temporarily unavailable, due to optimizations>, mid=<value temporarily unavailable, due to optimizations>, n=<value temporarily unavailable, due to optimizations>) at vm_eval.c:794
794 return rb_call(recv, mid, n, argv, CALL_FCALL);
(gdb) next
Program received signal EXC_BAD_ACCESS, Could not access memory.
from debase.
I've removed stack size calculation from context_create because it's no longer needed, probably should fix your problem
from debase.
Seems to work perfectly now. I'm able to set a break point and step through the code. The stepping seems more accurate now too. And performance-wise now it looks to be roughly identical to ruby 1.9 debug speed.
Thanks! This is a major improvement!
from debase.
Great!
I'm a little bit disappointed because I had to use Ruby VM internal headers to get proper stack size, but I'll try to discuss that with Koichi (debugger2 is suffering from the same problem) and probably we'll be able to improve that part too.
from debase.
I'm only seeing a slight performance increase with this update, not the same amount as other have reported.
6sec > Ruby 2.0 w debase 0.0.4
7sec > Ruby 2.0 w debase 0.0.3
3sec > Ruby 1.9.3
from debase.
Are you sure you're trying latest version from sources? These fixes are not pushed to rubygems yet. To make sure latest version is used by RubyMine you need to clone repo, and perform following commands:
bundle install
rake build
gem install pkg/debase-0.0.4.gem
On 27.08.2013, at 20:16, tleish [email protected] wrote:
I'm only seeing a slight performance increase with this update, not the same amount as other have reported.
6sec > Ruby 2.0 w debase 0.0.4
7sec > Ruby 2.0 w debause 0.0.3
3sec > Ruby 1.9.3—
Reply to this email directly or view it on GitHub.
from debase.
Yes, that's exactly how I installed it with the above results I reported.
from debase.
And what are run times (without debugger) on 2.0 and 1.9?
from debase.
I was incorrect. I cleared out everything and reinstalled my gems. I ran some additional tests and found it's just as fast as 1.9.3 now. I must've had an older 0.0.4 still in there.
Unit Tests Benchmark
13.63268s - 2.0.0
165.7345s - 2.0.0 w debase (0.0.3)
83.67467s - 2.0.0 w debase (head)
13.63268s - 1.9.3
83.97262s - 1.9.3 w ruby-debug-base19x
Very excited to have the debugging speed back. Thank you.
from debase.
That's good to hear, thank you!
from debase.
Related Issues (20)
- migrate tests to GHA HOT 1
- Debase gem not installing on MacOS Ventura and M1 HOT 2
- Debase failing to install on vscode Jekyll container HOT 1
- Failed to install in ruby docker image (vm_insnhelper.h missing) HOT 2
- Symbol not found: _rb_cObject on M1 Mac HOT 1
- Failed to install debase on Windows 10: is the new version for ruby-3.2.2 not releasing yet? HOT 3
- Can't install on mac os arm Mac OS Sonoma 14.4 HOT 9
- INTERNAL ERROR!!! ArgumentError: wrong number of arguments (given 2, expected 1)
- Error while installing debase-0.2.5.beta2 HOT 1
- Won't install with ruby 2.6.6 on macOS Big Sur HOT 12
- ERROR: Failed to build gem native extension - Mac(Catalina)+RVM(ruby 2.5.8) HOT 5
- 0.2.4.1 and 0.2.5.beta Fail to build on macOS Catalina 10.15.7 HOT 15
- Ruby 3.0.0 compatibilty HOT 10
- Missing tags for 0.2.4 and 0.2.4.1 release HOT 1
- Ruby 3.0.2 compatibilty HOT 11
- Ruby 3.1 compatibility issue HOT 5
- Debugger stops only on 1st breakpoint inside a Fiber block and ignores all subsequent ones
- debase failing to install on Mac HOT 1
- Failed to install Debase HOT 7
- Debbuger steps into internal kernel in ruby 3.x
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from debase.