Hacking on performance?

rubyonrails-core
1

@tenderlove talked at RailsConf about this being the year of making Rails leaner, faster, and less GC-inducing. I have a systems background, work with Rails all day, and want to contribute a few hours a week. Where’s a good place to dive in? Any patches that need collaborators, or ongoing discussions, or…? Has there been any traction on the idea of a new Rack API? I imagine that would need lots of gruntwork coding to make it happen.

Guidance and mentors welcome…

Jay Levitt

2

Hi Jay,

I think perusing Django's API would be a good first start. They handle things quite differently from Rack.

Here's a small gist of a sample API: https://gist.github.com/1185778

Cheers, Daniel

3

Cool, I was hoping the Rack thing was still in play. So some initial questions after looking at your Gist and reviewing Aaron’s slides, but before diving into the existing Rack API:

Technical:

  • I like the clear separation of “on the way in” vs “on the way out” in yours.

  • Aaron’s Filter objects have more of a lifecycle focus and explicit parameters - e.g. Filter is initialized (I guess Rack creates each middleware object here?), its #write gets called with explicit body, status, headers, and it gets a #close callback. Are you intentionally simplifying that, and does that have any implications for the HTTP streaming callback problem?

  • Likewise, what about the lifecycle hooks?

  • I’m still not quite clear on why stack depth has a huge GC impact, having never developed GC’s myself. Is it literally the number of stack frames that slows things down, or is it that stack depth implies a large number of objects that need marking as each frame makes local copies of the application state and modifies the request/response?

  • The history of Ruby GC tools is long and storied, but it seems the current generation of tools is railsbench with skaes’s rvm-patchsets, ruby-prof with its GCdata patch, and/or perftools. Yes?

  • How important is it to target each Ruby version? We don’t drop 1.8 support till 4.0. Do you see this as a 4.0 timeframe project or a 3.2 timeframe project? The GCs are vastly different, of course, and I don’t know enough to know if that will imply different strategies. I’m most worried about discovering that some strategy gives great results in 1.9.3 (hurray lazy sweeping) but has pathological implications for 1.8. Have you thought about that yet?

  • While we’re making sweeping API changes, I want to do it right, and I don’t have a lot of experience with the implications of seemingly-innocent Ruby choices. Any good mailing lists, blogs, etc. I should read up on? I’m thinking of stuff along the lines of Ernie Miller’s Enumerable discovery: http://erniemiller.org/2011/07/16/benchmarking-rubys-enumerable/

Logistical:

  • What has the Rack team’s response to these ideas been? It ain’t broke, it is broke but this ain’t it, we’re working on it too?

  • And thus, do you see this as going back into Rack, or as Rails providing a meta-unRack (your Rick?) as the lowest-layer middleware, calling new-style APIs instead of old APIs and never letting Rack call the application?

  • What do you see as the migration path from old to new? Aaron’s speech mentioned backwards-compatibility. Do you think newly-enlightened middleware will just expose both APIs, with old Rack calling one and new Rack calling the other? Or should the compatibility layer be built into R[ai]ck, as I asked above?