Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times

rubyinside.com

Post reply on HN
Print view View original

11–20 of 23 posts

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

#11

Post by davidk0101 »

burke wrote: post #7
aneth wrote: 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.

Ruby is much more than Rails and I think it's a little sad that a large portion of the developer population has no idea that Ruby exists outside of Rails.

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

#13

Post by Vitaly »

davidk0101 wrote: post #11
burke wrote: post #7

Earlier quoted context omitted.

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.

Ruby is much more than Rails and I think it's a little sad that a large portion of the developer population has no idea that Ruby exists outside of Rails.

i find it a little sad that the core people find it appropriate to ignore needs of a framework that brought the language from the obscurity it "enjoyed" for years to the front lines where it is now.

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

#14

Post by Andys »

aneth wrote: 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…

Because the #1 priority is to make programming, not loading rails, enjoyable. And there can't be two #1 priorities.

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

#15

Post by plastics »

Vitaly wrote: post #13
davidk0101 wrote: post #11

Earlier quoted context omitted.

Ruby is much more than Rails and I think it's a little sad that a large portion of the developer population has no idea that Ruby exists outside of Rails.

i find it a little sad that the core people find it appropriate to ignore needs of a framework that brought the language from the obscurity it "enjoyed" for years to the front lines where it is now.

Ruby was popular in Japan long before Rails.

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

#16

Post by awj »

ballard wrote: post #12

There's an old solaris rationalization: "It's not the time it takes to reboot, but how often."

Not to nit-pick your joke, but the unfortunate case in the Rails world is very often. I (try to) be a good boy and run tests before every check in, as well as writing them in advance of new features. Our project has enough files that it takes ~30-40s for the environment to load.

On an average day I probably spend 30 minutes to an hour of each day waiting on environment loading, depending on the task. Big restructurings and big new features tend to take a lot of test iterations.

Now that I do the numbers my time sunk on this is simply staggering.

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

#17

Post by aneth »

patio11 wrote: post #9
aneth wrote: 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…

By extension, Rails is built on a house of cards - a language team that does not intend to support it, and doesn't care if they cause a majority of their international users a great deal of pain. That would be, as I said before, disappointing and frustrating.

While the MRI team benefits enormously from the international success of Ruby that is largely attributable to Rails, you are right that they are not technically obligated to promptly fix egregious performance regressions. A certain portion of the developer community might feel that it is irresponsible not to support your user base.

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

#18

Post by molecule »

awj wrote: post #16
ballard wrote: post #12

There's an old solaris rationalization: "It's not the time it takes to reboot, but how often."

Not to nit-pick your joke, but the unfortunate case in the Rails world is very often. I (try to) be a good boy and run tests before every check in, as well as writing them in advance of new features. Our project has enough files that it takes ~30-40s for the environment to load. On an average day I probably spend 30 minutes to an hour of each day waiting on environment loading, depending on the task. Big restructurin…

ouch. that makes a profound productivity regression.

/obvious

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

#19

Post by tptacek »

aneth wrote: post #17
patio11 wrote: post #9

Earlier quoted context omitted.

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…

By extension, Rails is built on a house of cards - a language team that does not intend to support it, and doesn't care if they cause a majority of their international users a great deal of pain. That would be, as I said before, disappointing and frustrating. While the MRI team benefits enormously from the international success of Ruby that is largely attributable to Rails, you are right that they are not technically…

In open source, nobody is entitled to someone else's time and energy. But that's what the word "irresponsible" implies. So, I think you should choose your words more carefully.

As regards the technical problems you're talking about, switch Rubies (I'm a fan of JRuby), or fork MRI.

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

#20

Post by plastics »

robryan wrote: post #4
aneth wrote: 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 also possible, that real world Ruby applications are - in Japan - generally not written using Rails.
Post reply on HN