The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
1–10 of 23 posts
Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#2Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#3Why is this not the #1 priority for the MRI team?
Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#4I 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…
Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#5Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#6I 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
#7I 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…
Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#8Earlier 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.
Re: The Story Behind Ruby 1.9.3 Getting 36% Faster Loading Times
#9I 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…
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
#10I 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…