git, a million times git!
At the very least, having a filesystem-level undo has saved my bacon more times than I can count, and once you figure out branching you'll see your coding confidence being to soar as you realize you can
always go back to a known state. Want to try a crazy new idea, or refactor a huge swath of code? Don't even worry about it, just branch and go. I've used source control before (perforce, svn, horrible old VSS) but having git so available, so fast, and so bulletproof entirely changed how I work as a programmer. No joke!
On a more game-oriented note, I just found myself using the ruby-prof gem (
https://github.com/rdp/ruby-prof) to generate cachegrind output, which can then be loaded and analyzed in the free KCacheGrind. You can have ruby-prof spit out cachegrind reports like so:
require 'ruby-prof'
result = RubyProf.profile do
window.show
end
printer = RubyProf::CallTreePrinter.new(result)
f = File.new('tmp/call_tree', 'w')
printer.print(f, {})
If you're trying to optimize your framerates, just have the game do a (preferably) automated and repeatable set of repro steps during the window.show loop, and once the steps have completed, open the file in KCacheGrind and you can see exactly where your program spent most of it's cycles. The results can be surprising, and surprisingly effective. I was lagging frames really badly once I got up to a certain number of onscreen objects, and spent time trying to optimize iteration and variable creation and got nowhere. Fired up the cachegrind viewer, though, and immediate saw several million calls to a color calculation method deep in an inner loop. I didn't realize it was being called that deeply, since it was layered seven or eight levels deep from the top of the show/update stack inside a call to an accessor method. I cached the value, re-ran the tests, and immediate saw an almost 25 FPS improvement on the same test battery. O_O
