Rails Takes Ten Seconds (!)
Alex Chaffee
Half of them are on Macs and the other half are on Windows and used
RailsInstaller (latest version, downloaded this morning) to install on
fresh systems. Whenever the Windows users type any rails command from
the terminal -- including "rails -v" -- there is a 10 second delay
before anything starts happening. Same with "gem -v" (though some
students say "gem -v" takes 3-4 seconds), though "ruby -v" returns
immediately.
The Mac users, of couse, are experiencing no such delays; the Windows
users are learning that Ruby is slow :-)
Is this a known issue? Is there anything we can do about it? It is
*seriously* impeding flow.
We are using rails 3.1.1 and gem 1.7.2 which are the versions
Railsinstaller installed.
If we hit control-C during the pause we get a stack trace somewhere
inside the gem require library, e.g. custom_require.rb:36 (which calls
gem_original_require). Could rubygems be hitting the network or timing
out for some reason?
--
Alex Chaffee - al...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch
Luis Lavena
Removing rubygems-developer since this has nothing to do with RubyGems.
On Tue, Jan 17, 2012 at 8:36 PM, Alex Chaffee <al...@stinky.com> wrote:
> I'm teaching a class right now and I have a room full of students.
> Half of them are on Macs and the other half are on Windows and used
> RailsInstaller (latest version, downloaded this morning) to install on
> fresh systems. Whenever the Windows users type any rails command from
> the terminal -- including "rails -v" -- there is a 10 second delay
> before anything starts happening. Same with "gem -v" (though some
> students say "gem -v" takes 3-4 seconds), though "ruby -v" returns
> immediately.
>
Ruby 1.9.3 brings back Ruby 1.8.7 performance, yet still Ruby on
Windows is slower than UNIX (Linux or OSX).
> The Mac users, of couse, are experiencing no such delays; the Windows
> users are learning that Ruby is slow :-)
>
> Is this a known issue? Is there anything we can do about it? It is
> *seriously* impeding flow.
>
Yes, is a well known issue.
> We are using rails 3.1.1 and gem 1.7.2 which are the versions
> Railsinstaller installed.
>
> If we hit control-C during the pause we get a stack trace somewhere
> inside the gem require library, e.g. custom_require.rb:36 (which calls
> gem_original_require). Could rubygems be hitting the network or timing
> out for some reason?
>
This has nothing to do with RubyGems or network, is a Ruby design
issue on Windows.
Please see this:
http://blog.mmediasys.com/2011/11/26/rubyconf-argentina-and-fenix/
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Keegan Black
Yeah, no clue to exactly why but I'm on windows 7 and have the same issue.
Brian Hogan
case with certain Windows configurations. We see this often on older
laptops. For a short time things got faster but then Rails got a
little more bulky.
Brian Hogan
Alex Chaffee
long time, but since I personally use Macs it would only come up
during classes or workshops and I would always forget to track it down
later. It's especially odd since it seemed to vary from system to
system but without respect to CPU speed.
(BTW, File.expand_path? OMFG. That method is used *everywhere* at file
load/require time and almost never afterwards. No wonder it behaves
like a single giant pause during rubygems require.)
I know the next Railsinstaller release will be using Ruby 1.9.3; any
estimate on when we can expect that to come out? And if not, is it OK
to use Rubyinstaller's 1.9.3 package from
http://rubyinstaller.org/downloads/ on top of Railsinstaller's 1.9.2?
(I have a lab rat-- uh, I mean helpful student "volunteer" trying that
out now.)
- A
Wayne E. Seguin
Do you give blessing for doing a RailsInstaller release of 1.9.3 on Windows?
Has it been stable enough in your experience?
~Wayne
Luis Lavena
<waynee...@gmail.com> wrote:
> Luis,
>
> Do you give blessing for doing a RailsInstaller release of 1.9.3 on Windows?
> Has it been stable enough in your experience?
>
Yes, I've nuked every other Ruby release 1.9.*, I use 1.9.3 on a daily
basis and is quite stable and way faster than 1.9.2.
> ~Wayne
>
> On Jan 17, 2012, at 7:56 PM, Alex Chaffee wrote:
>
>> Thanks for the quick, clear response! This has been bugging me for a
>> long time, but since I personally use Macs it would only come up
>> during classes or workshops and I would always forget to track it down
>> later. It's especially odd since it seemed to vary from system to
>> system but without respect to CPU speed.
>>
>> (BTW, File.expand_path? OMFG. That method is used *everywhere* at file
>> load/require time and almost never afterwards. No wonder it behaves
>> like a single giant pause during rubygems require.)
>>
>> I know the next Railsinstaller release will be using Ruby 1.9.3; any
>> estimate on when we can expect that to come out? And if not, is it OK
>> to use Rubyinstaller's 1.9.3 package from
>> http://rubyinstaller.org/downloads/ on top of Railsinstaller's 1.9.2?
>> (I have a lab rat-- uh, I mean helpful student "volunteer" trying that
>> out now.)
>>
>> - A
>>
>> --
>> Alex Chaffee - al...@stinky.com
>> http://alexchaffee.com
>> http://twitter.com/alexch
>
--
Ken Collins
I wonder how long until Rails 3.2 comes out of RC status. FWIW, I'll release update versions of the adapter and TinyTDS as soon as that happens.
- Ken
Alex Chaffee
http://itreallymatters.net/post/12897174267/speedup-ruby-1-9-3-on-windows
My student failed last night -- the RubyInstaller instructions for using DevKit to set up a "sane environment" to allow native gems like json to compile during gem install were too confusing -- but hopefully today either we'll muddle through or Wayne will push a new RailsInstaller release.
- A
Wayne E. Seguin
Wayne E. Seguin
Can you and/or your student send a patch for the instructions that would make them make sense / be easy to follow?
Ken Collins
Thanks Wayne! And yes, of course TinyTDS passes on 1.8.6 to 1.9.3. I wish I was able to hook it up to TravisCI, but I do test it on all rubies manually which is why it always takes me awhile to put out a release.
- Ken
Alex Chaffee
The rest of the Windows users just either paired up with Mac users or suffered through every ruby command taking upwards of a minute or more to execute. (10 seconds, it seems, was merely a lower bound.) Spork helped a bit.
Sent from my iPhone
Alex Chaffee
RailsInstaller with the new 1.9.3)
On Fri, Jan 20, 2012 at 11:13 AM, Luis Lavena <luisl...@gmail.com> wrote:
> On Fri, Jan 20, 2012 at 3:06 PM, Alex Chaffee <ale...@gmail.com> wrote:
>> (offlist)
>>
>> ...but I think it'd likely be no problem for you. We got stuck in the
>> instructions on how to put devkit into RubyInstaller; I'm pretty sure
>> you've already done that in the process of putting RailsInstaller
>> together. (I mean, you can run "gem install json" from inside "Command
>> Prompt With Ruby And Rails" so that must work.) And I don't have a
>> windows machine handy here on the road to try to muck through it
>> myself.
>
> RubyInstaller + DevKit:
>
> https://github.com/oneclick/rubyinstaller/wiki/Development-Kit
>
> Is not that complicated, however having RailsInstaller *installed*
> could affect it.
I'd say it's medium-complicated :-)
And at any rate too complicated for someone who doesn't have a good
idea where RailsInstaller put all its files, especially on the fly
during a class... but yeah, all the steps do seem to be there for
someone with sufficient focus.
> To update the version of Ruby for RailsInstaller is easy:
>
> https://github.com/railsinstaller/railsinstaller-windows/blob/2.0.0/config/railsinstaller.yml#L38-44
>
> And here I believe:
> https://github.com/railsinstaller/railsinstaller-windows/blob/2.0.0/lib/railsinstaller/actions.rb#L5-8
The URL to the 1.9.3 build recommended by Jarmo[1] is
https://github.com/downloads/thecodeshop/ruby/tcs-ruby193_require_winio_fenix-20111113.7z
Luis, is that a good build, or is there a better one?
- A
[1] http://itreallymatters.net/post/12897174267/speedup-ruby-1-9-3-on-windows
Luis Lavena
> (back on-list, in case someone other than Wayne wants to build
> RailsInstaller with the new 1.9.3)
>
And back, and forth, and the other way around :P
> On Fri, Jan 20, 2012 at 11:13 AM, Luis Lavena <luisl...@gmail.com> wrote:
>> On Fri, Jan 20, 2012 at 3:06 PM, Alex Chaffee <ale...@gmail.com> wrote:
>>> (offlist)
>>>
>>> ...but I think it'd likely be no problem for you. We got stuck in the
>>> instructions on how to put devkit into RubyInstaller; I'm pretty sure
>>> you've already done that in the process of putting RailsInstaller
>>> together. (I mean, you can run "gem install json" from inside "Command
>>> Prompt With Ruby And Rails" so that must work.) And I don't have a
>>> windows machine handy here on the road to try to muck through it
>>> myself.
>>
>> RubyInstaller + DevKit:
>>
>> https://github.com/oneclick/rubyinstaller/wiki/Development-Kit
>>
>> Is not that complicated, however having RailsInstaller *installed*
>> could affect it.
>
> I'd say it's medium-complicated :-)
>
> And at any rate too complicated for someone who doesn't have a good
> idea where RailsInstaller put all its files, especially on the fly
> during a class... but yeah, all the steps do seem to be there for
> someone with sufficient focus.
>
I did say RubyInstaller + DevKit, and clarified: having RailsInstaller
installed could affect the installation of it.
I did a brief class and for that we used RubyInstaller + DevKit + gems
and went smoothly, I wouldn't recommend altering too much an
installation of RailsInstaller.
>
> The URL to the 1.9.3 build recommended by Jarmo[1] is
> https://github.com/downloads/thecodeshop/ruby/tcs-ruby193_require_winio_fenix-20111113.7z
>
> Luis, is that a good build, or is there a better one?
>
Is not an official RubyInstaller build, I can't support it while it
contains lot of optimizations.
Alex Chaffee
>> https://github.com/downloads/thecodeshop/ruby/tcs-ruby193_require_winio_fenix-20111113.7z
>>
>> Luis, is that a good build, or is there a better one?
>
> Is not an official RubyInstaller build, I can't support it while it
> contains lot of optimizations.
Uh-oh! Luis, are you saying that if Wayne builds a new RailsInstaller
then it might not actually fix the slowness bug? Or does Wayne have
everything he needs to patch Ruby with at least your File.expand_path
fix?
Sorry if I'm being a nervous mother hen about this, but as far as I'm
concerned this is a showstopper bug and I really want my next batch of
students to have a Ruby that isn't completely unusable (not to mention
the rest of the world).
- A
Luis Lavena
>>> The URL to the 1.9.3 build recommended by Jarmo[1] is
>>> https://github.com/downloads/thecodeshop/ruby/tcs-ruby193_require_winio_fenix-20111113.7z
>>>
>>> Luis, is that a good build, or is there a better one?
>>
>> Is not an official RubyInstaller build, I can't support it while it
>> contains lot of optimizations.
>
> Uh-oh! Luis, are you saying that if Wayne builds a new RailsInstaller
> then it might not actually fix the slowness bug? Or does Wayne have
> everything he needs to patch Ruby with at least your File.expand_path
> fix?
>
Let me clarify things and let's step back for a second:
- Ruby 1.9.2 is damn slow on Windows
- Ruby 1.9.3 brings performance similar to 1.8.7 back on Windows
- Both Ruby 1.9.3 and 1.8.7 are still considerable slow on Windows.
- RailsInstaller is build on top of *official* RubyInstaller releases
- TheCodeShop releases, while it contains a set of patches that
improve considerable the speed of Ruby, are still *experimental*.
definitely I won't build a product on that level of experimental, even
if is quite stable, lot of things hasn't been tested.
> Sorry if I'm being a nervous mother hen about this, but as far as I'm
> concerned this is a showstopper bug and I really want my next batch of
> students to have a Ruby that isn't completely unusable (not to mention
> the rest of the world).
>
<rant>
If you consider Ruby speed a showstopper bug, perhaps you can point
that to Ruby-Core, for them speed is not a bug, is a feature, and
Windows has never received the share of respect and attention it
deserves.
Nothing at RubyInstaller or RailsInstaller project could do to fix
that except going the *forked* set of patches which is not what
TheCodeShop or RubyInstaller want to achieve (can't talk about
RailsInstaller)
RubyInstaller with the complementary DevKit installation are quite
stable and under certain scenarios only had a few issues with certain
*unfriendly* gems.
</rant>
I've expressed my opinion in the past about all the above, Ruby speed
and everything here and RubyInstaller groups. I don't think there is
anything else to say except that help is always welcome.
Alex Chaffee
> - Ruby 1.9.2 is damn slow on Windows
> - Ruby 1.9.3 brings performance similar to 1.8.7 back on Windows
> - Both Ruby 1.9.3 and 1.8.7 are still considerable slow on Windows.
Got it now, thanks. (I've had your presentation open in a tab and
finally got to the slides with the graphs on 'em. Yikes!)
> If you consider Ruby speed a showstopper bug, perhaps you can point
> that to Ruby-Core, for them speed is not a bug, is a feature, and
> Windows has never received the share of respect and attention it
> deserves.
I'd be happy to help however I can. Between my private classes and
Railsbridge workshops, I see about 50 new people per month suffering
on either installing or running Ruby on Windows. Is there's a bug they
can vote up, or a StackOverflow thread they can add a comment to, that
Ruby Core will pay attention to? Does anyone know Matz' private cell
number so we can leave him irate voicemails? ;-)
I greatly appreciate all the work that's been done by the
RailsInstaller, RubyInstaller and RVM projects -- as well as whatever
tools they depend on -- and I agree with you that it's shameful that
Ruby Core hasn't prioritized fixing such a horrendous bug. Many people
have Windows installed on their home or work machines and this is
essentially giving all of them a negative first experience with Ruby
and Rails, and driving many of them into the arms of Python, or at
least back to Java. Isn't the Ruby community supposed to be inclusive
and welcoming and diverse?
By the way, I spent a lot of time over the past year organizing the
Installfest web site which is meant to contain clear, step by step
instructions on installing Ruby etc. on all platforms. It's currently
tailored to the Railsbridge workshop but it can be used by anyone.
Suggestions and pull requests are welcome!
http://installfest.railsbridge.org
https://github.com/railsbridge/installfest
> [for Ruby-Core, slow] speed is not a bug, is a feature
I hope you don't mean that literally! How can slowness be a feature?
Luis Lavena
>
> Isn't the Ruby community supposed to be inclusive
> and welcoming and diverse?
>
I said the same, also my slides showed that. Ruby itself is not as bad
to welcome different platforms. Mood gets twisted once you talk to
Ruby developers that learn or use the language through Rails.
> By the way, I spent a lot of time over the past year organizing the
> Installfest web site which is meant to contain clear, step by step
> instructions on installing Ruby etc. on all platforms. It's currently
> tailored to the Railsbridge workshop but it can be used by anyone.
> Suggestions and pull requests are welcome!
>
> http://installfest.railsbridge.org
> https://github.com/railsbridge/installfest
Good to know, will keep those in mind and probably send some comments :-)
>
>> [for Ruby-Core, slow] speed is not a bug, is a feature
>
> I hope you don't mean that literally! How can slowness be a feature?
>
If you send patches that change internals to increase speed they are
not accepted if they are in feature freeze mode, for example,
optimizations for hashes that are in trunk will never be backported to
1.9.3 branch.
<rant>
In the case of Windows implementation of Ruby (the C side), I can say
that its design has been made around a layer that mimics unix so other
developers can use things like open and sockets work the same way.
But because of that, lot of code has been added to do things that way
and not how their are supposed to be done in the platform.
Introduce changes to fix that are mostly impossible and we need to be
careful to change stuff and not break everything.
</rant>
And I can continue ad nauseam on this topic, so better leave it here
and keep hacking some code that improve things :-)
Cheers,
Sam Ruby
Rails 3.2 came out yesterday and has performance improvements
Ken Collins
Rails 3.2 came out yesterday and has performance improvements
Luis Lavena
That must be related to the change of extconf.rb options change from last time.
Will take a look on Monday with my Mac.
Sorry for top posting. Sent from mobile.
Luis Lavena
> That must be related to the change of extconf.rb options change from last
> time.
>
Yes, was related to the extconf.rb changes and the forced lookup of
directories for dir_config.
No blaming, but looking over existing directories to use these options
over letting the system determine which directory to use is a bit
risky.
Should be fixed now:
https://github.com/rails-sqlserver/tiny_tds/commit/208c4ad96377090836ea40bd938039d99ef3c55f
Ken Collins
> Yes, was related to the extconf.rb changes and the forced lookup of
> directories for dir_config.
Yea, remember that was driven by this ticket.
https://github.com/rails-sqlserver/tiny_tds/issues/11
A nightmare back and forth, but I will try to QA _all_ is good now.
Thanks a ton!
- Ken
Wayne E. Seguin
Alex Chaffee
esp. "Windows users will be glad to hear that Yura's four patches that make up
https://gist.github.com/1658360#gistcomment-77812
also work quite well with MRI 1.9.3 built using the RubyInstaller
recipes. I've not yet tried building using Windows SDK 7.1, but I
suspect they work just fine."
Luis Lavena
> FYI: http://www.ruby-forum.com/topic/3490236
>
> esp. "Windows users will be glad to hear that Yura's four patches that make up
>
> https://gist.github.com/1658360#gistcomment-77812
>
> also work quite well with MRI 1.9.3 built using the RubyInstaller
> recipes. I've not yet tried building using Windows SDK 7.1, but I
> suspect they work just fine."
>
Indeed, those patches speed up Ruby on any platform, not just Windows.
There is a also a hash pool technique which reduces memory allocation,
specially considering Rack and Rails known usage of lot of hashes
per-request.