The Fastest Ruby Debugger in the West
One of the problems with “traditional” Ruby is the (notoriously) slow debugger. The Ruby In Steel Cylon debugger isn’t just the fastest Ruby debugger available it’s also the most functional, with several new features that I’ve just added.
When we first started out on building RiS, one of our main objectives was to have a fast debugger. Not only that, but to have the fastest debugger around. We’ve achieved this by using a combination of assembly language programming, careful optimization – and one or two other sneaky tricks (learnt from years of programming fast real-time systems) that I won’t go into here.
There are two other debuggers with which Cylon can be compared – the original ‘slow’ Ruby debugger and a faster one written in C – ‘ruby-debug’. There are two fundamental benchmarks that can be used to compare the intrinsic performance of various debuggers: a ‘line’ based benchmark and a ‘call’ based one. These are the basic figures (in seconds):
As you can see, Cylon is about twice as fast as ruby-debug in the line based benchmark and about 70% faster in the call based one. I’ll explain how the benchmarks were done and give some more details on use of breakpoints, etc. next week, but the bottom line is for all benchmarks Cylon is between 50% and 100% faster (approximately) than ruby-debug. Compared to the slow debugger, Cylon is typically between 100 and 150 times faster than the slow debugger.
I’ll just briefly list the main new features we’ve put into Cylon:
In addition to displaying Ruby data, you can set and modify Ruby variables and data in a watch window.
Conditional breakpoints are now implemented, i.e. a breakpoint will only become active if a Ruby expression is true or alternatively a data value has changed.
Breakpoint counts now work, so you can fire a breakpoint after say 4 passes.
Visual Studio Tracepoints now work.
Restarting the debugger from the Visual Studio IDE now works.
Break All is implemented. This is if you select Break All, the debugger will fire.
Just in Time exception handling works: if an exception occurs, the debugger will fire instead of passing the exception to the handler.
Over the next couple of weeks, I’ll describe these new features (and a couple more) in more detail.
these features are only available in Cylon/RiS 1.2 (to be released shortly).
Cylon is only available in the Developer Edition.
great work this Ruby in Steel, but there is one thing that drives me crazy. Its about the auto completition feature in intellisense. Is there some possibility to include installed gems ? It would be very helpful if so. Annother point is, that a require directive including a gem lib or so, always throws a warning. Execution is no prob, but this warning stays.
Besides this points, this Combination VS 2005/2008 + RiS seems to be the best IDE flying around (and the fastest; i tried all the boomers, netbeans, kommodo,etc. ) Congrats on that ...
Do you mean generating compiled IntelliSense for a selected Gem so that the IntelliSense system ’knows’ about the Gem?
(Rails is currently done like this).
I’ve got a neraly finished ’Librarian’ function that allows you to compile IntelliSense for a selected file, but I hadn’t thought of doing it on a Gem basis.
The Librarian allows you to select a group of files and to generate IntelliSense. I think I could extend this to Gems reasonably easily.
Thanks for your excellent debugger. This is probably one of my favorite reasons for using RiS. The ability to set breakpoints at any point in code (even in erb) and easily and quickly inspect values really increases my productivity tremendously. I am definitely becoming very dependent on RiS and would not want to move to any other IDE.