what's your rails wishlist?

Charlie Bowman wrote: > What's in your wishlist for rails?

1) Thread safety in ActionPack 2) Thread pooling in ActiveRecord

These are 'magic beans' features whose importance deserve to be thoroughly deflated.

3) Smaller memory footprint 4) Saner Ruby GC that takes copy-on-write into account (would help a lot with 3))

These are extremely valuable. Some folks have been making great strides here in the past 6 months.

Hongli Lai has modified Ruby GC to be CoW-friendly and Matz has expressed interest in merging with Ruby 1.9: http://izumi.plan99.net/blog/index.php/category/optimizing-rails/

The Acunote crew have been doing extensive memory profiling and their patches are going straight to Rails trunk: http://blog.pluron.com/2008/02/memory-profilin.html

Best, jeremy

3) Smaller memory footprint 4) Saner Ruby GC that takes copy-on-write into account (would help a lot with 3))

These are extremely valuable. Some folks have been making great strides here in the past 6 months.

Hongli Lai has modified Ruby GC to be CoW-friendly and Matz has expressed interest in merging with Ruby 1.9: http://izumi.plan99.net/blog/index.php/category/optimizing-rails/

Wow the new code for the GC looks a lot nicer than the old. Note however that it still reads all allocated memory (I believe) -- just doesn't write to all of it anymore per sweep. Also note that it still uses mark and sweep so this may not be the optimal solution yet. More like a patch of the working one with mostly similar characteristics, and some speed up. Looks nicer than it used to be. -Roger

Based on 2 years of Rails experience, as of next month, here's my wish list:

1) Comprehensive deprecation and _removal_ information - something better than http://www.rubyonrails.org/deprecation. Ideally, a utility that would scan your project and report on what would need to change to move it to newer Rails version X. Is API call deprecated in version X? Is API call _gone_ in version X?

2) api.rubyonrails.org documentation that includes the version of Rails at which an API call was introduced and whether it's been deprecated or not (for Java people, something akin to @since and @Deprecated Javadoc tags)

3) Support for prepared statements in ActiveRecord

4) Support for DB connection pooling in (a layer above, perhaps) ActiveRecord

Wes

Jeremy Kemper wrote:

Charlie Bowman wrote: > What's in your wishlist for rails?

1) Thread safety in ActionPack 2) Thread pooling in ActiveRecord

These are 'magic beans' features whose importance deserve to be thoroughly deflated.

I disagree. Thread safety in ActionPack would allow you to use fewer processes in production, which would help memory usage. I'm not saying it is very important, but that doesn't mean it doesn't belong on a wishlist.

A bigger isssue is the lack of connection/thread pooling in ActiveRecord, which makes it pretty unusable for web frameworks such as Ramaze. With allow_concurrency = false, if two requests need access to the database at the same time, one fails, as there is no thread safety. If you set allow_concurrency = true, every request gets its own connection, but garbage collection doesn't kick in and you eventually run out of resources (that could be a problem with the database adapter and or Ramaze leaving references to the thread open, though).

These features are obviously important to the people designing alternative ruby web frameworks such as Ramaze and Merb and ORMs such as Sequel and DataMapper.

Obviously it is easier to ignore thread safety, but do you believe that ActionPack would be worse off if it were thread safe, or that ActiveRecord would be worse off if it supported connection pooling?

3) Smaller memory footprint 4) Saner Ruby GC that takes copy-on-write into account (would help a lot with 3))

These are extremely valuable. Some folks have been making great strides here in the past 6 months.

Hongli Lai has modified Ruby GC to be CoW-friendly and Matz has expressed interest in merging with Ruby 1.9: http://izumi.plan99.net/blog/index.php/category/optimizing-rails/

I've read about this work, but I did not know that Matz was interested. I certainly hope it gets applied.

The Acunote crew have been doing extensive memory profiling and their patches are going straight to Rails trunk: Make Your Ruby/Rails App Fast: Performance And Memory Profiling Using ruby-prof and KCachegrind - Acunote Blog

That's good to know.

Thanks, Jeremy