Live data from Hacker News

The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

rubyinside.com

1–10 of 23 posts

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#2
This directly relates to a popular HN story from the other day: http://news.ycombinator.com/item?id=2594668 (in the sense that the solution outlined in that story has sort of been evaded by some optimizations made by Ruby core - temporarily, hopefully).

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#3
I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad for Rails.

Why is this not the #1 priority for the MRI team?

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#4
post #3

I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad…

Without knowing anything about the core ruby developers, it's possible most of them are detached from current real world ruby applications with heavy weight frameworks?

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#6
post #4
post #3

I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad…

Without knowing anything about the core ruby developers, it's possible most of them are detached from current real world ruby applications with heavy weight frameworks?

It's amusing that Rails is now considered a heavy framework. I remember writing my first Rails app with Rails 0.8. It was a tremendous breath of fresh air then. Seven years later it's the bloated incumbent.

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#7
post #3

I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad…

Agreed. This is why I really, really hope Rubinius manages to become "worth it" soon (or at least JRuby). The MRI core team, Tenderlove excluded, seem to give approximately zero shits about Rails.

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#8
post #6
post #4

Earlier quoted context omitted.

Without knowing anything about the core ruby developers, it's possible most of them are detached from current real world ruby applications with heavy weight frameworks?

It's amusing that Rails is now considered a heavy framework. I remember writing my first Rails app with Rails 0.8. It was a tremendous breath of fresh air then. Seven years later it's the bloated incumbent.

there's always merb 1.1

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#9
post #3

I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad…

What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications?

Step 1: Learn to speak Japanese. Step 2: Express that the startup speed of a project that, IIRC, none of them use and that doesn't pay the bills at their day jobs is Really Really Important To White People and that anything which compromises its utility -- which should be checked exhaustively at every release -- should block shipping.

I use Rails, and love Rails, but back home Rails is not yet the core Ruby use case, not by a long shot. Rails has peculiar needs with regards to typical Ruby applications, and a certain portion of the developer community feels that people who write themselves peculiar needs can write their own solutions to them. (i.e. "If they're going to run tests every few seconds and load a thousand files every time it runs... why is poor performance our problem again?")

Apologies for being a wee bit snippy but variations on this discussion have come up before.

Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

#10
post #3

I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad…

How does that compare to, say, loading Java application stack? How much of total application lifecycle does loading time take? This is not to say, that no fix needed, just that it is possible that impact is much less important.
Post reply on HN