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:
http://blog.pluron.com/2008/02/memory-profilin.html

That's good to know.

Thanks,
Jeremy