Similar issue to Slow loading rails environment
Loading the rails environment takes quite a bit of time and I'm not sure exactly why.
time ruby -r./config/environment.rb -e ""
real 0m18.590s
user 0m17.200s
sys 0m1.320s
Are there any tools/ways that can help me find why it is spending so much time to load the environment?
The project is fairly large, so I am assuming that it is coming from all the gem dependencies, but I would think that it would be able to be improved somehow.
If you are using Ruby 1.9 then see this blog post it may be the issue you are experiencing. If it is it has to do with the amount of requires in your project and the way that method is implemented in 1.9. There is a patch available to improve this performance.
I tried patching my ruby with the rhnh patch cited above as well as the rvm-patchsets (on independent ruby installs of course) but didn't pick up a lot of performance. But some do it seems so maybe it's a ruby version or lower level issue.
My current workaround, at least in my dev environment, is to use rails-sh to preload the environment one time and then reuse it in your rails/rake commands. It's a big performance pickup. Wrote more details on it in this answer.
Related
Full disclosure. I do not use Ruby. I never have even looked into learning it as a language.
We use ruby at our company to power an integration between a couple of our tools. Due to a TLS update we have to update our ruby version from 1.9.2 to the newest version.
On this windows server 2008 r2 machine I have that version of ruby and need to update. The problem is this tool is in constant use. So I cannot reasonably take the server down for a whole day while I try to figure out what to do. Initial research shows that these older versions of ruby are problematic to update.
I have only a half dozen gems to worry about (and found a really good guide on updating those - I think).
Looking for a kind soul who is willing to help a lost soul.
Is this a case of needing to completely uninstall and if so does that mean uninstall my gems as well? Or can I just run an update via cmd?
This is mostly going to come down to your gem dependencies.
As for just the language, the odds of encountering anything that works with Ruby 1.9.3, but not Ruby 2.0+ will be highly unlikely. Plenty of features have been added, but on a whole, backwards compatibility has been maintained.
This is not necessarily the case with gems, as the dependencies and robustness of the code can vary wildly depending on the source. The only real way to answer anything with confidence is to check/compare dependencies of each gem you require with your target Ruby version. Typically increasing the Ruby version is less likely to "break" anything than lowering it obviously, but it is still a significantly plausible scenario you must be wary of and prepare against.
The only real way to do this without downtime is to clone or setup a new environment for testing, install the newer Ruby, install the required gems you have researched dependencies, and test to make sure everything runs/works as expected.
Unfortunately there is no "magic bullet" here that is going to solve this issue for you. Luckily, the vast majority of this does not require knowledge of Ruby syntax and coding, and if everything goes well, will require nothing more than installing Ruby, installing gems, and comparing versions. If you run into issues with specific gems, I am confident that there is a host of people here on SO that can help guide you through reconciling it.
I've been using quite a number of Python modules such as Numpy in large machine learning projects. Previously, I used Django for the web application and mod_wsgi as a front end to these. Now, someone is making the case to transfer to Ruby on Rails. Are similar libraries available for Ruby?
As Benjamin Tan pointed out, SciRuby is working on this. Commenters rightly noted that not much work has been done on the sciruby gem, but NMatrix is under extremely active development. The goal is to replace NArray.
There are also quite a few stable gems associated with SciRuby: Statsample, distribution, minimization, integration, Rubyvis (a Ruby port of Protovis), and so on.
SciRuby actually just got Google Summer of Code support, too, and a grant from the Ruby Association a few months ago, so we're hopeful that it will go places.
Full disclosure: I'm one of the lead developers for NMatrix and a co-founder of the SciRuby project.
The closest would be SciRuby.
I'm trying to profile GC in a non-Rails application, preferably using YARV Ruby.
perftools.rb is telling me that the majority of my CPU time is spent in garbage_collector (6061 (61.4%)).
I'm also able to get how many objects are created by which methods with perftools.rb . Some methods create more objects than others, but it's not extremely skewed.
Where do I go from here? Is it possible to get more detailed information on why it's spending so much time doing GC? Is it possible to see whether the time is spent getting rid of objects, or whether it is spent checking whether an object should be garbage collected or not?
I have access to OS X Lion, Windows 7 and Ubuntu 12.04.
On osx you have dtrace. There are dtrace providers in YARV ruby.
You have a couple of probes related to GC that you can use:
gc-begin
gc-end
gc-mark-begin
gc-mark-end
gc-sweep-begin
gc-sweep-end
I think they can help finding what the GC in your program is doing. have a look at this file to see how use them: https://github.com/tenderlove/ruby/blob/probes/test/dtrace/test_gc.rb.
And this post for more explanations: http://tenderlovemaking.com/2011/06/29/i-want-dtrace-probes-in-ruby.html
There's a bug opened in ruby http://bugs.ruby-lang.org/issues/2565 where you can find a patch to apply to ruby to have those probes or you can use https://github.com/tenderlove/ruby/tree/probes where the patch is already applied.
Hope this helps
I've got a ruby script which takes about 30 seconds to startup. It takes that much because it tries to load all libraries and stuff.
When I do ruby.exe -v it's instant.
I don't want to touch the original ruby script, which is not written by me.
What are the tricks to speed this process up?
Can I precompile it?
Can I precache all of these files?
I need to do this under Windows or Cygwin.
UPDATE :
Scripts is quite slow in Linux/Mac as well, this condition is not specific to Windows.
This is normal ruby 1.8.7 (similar speed in other ruby versions)
Main bottleneck is loading so many libraries (I removed unrequired files and libraries and decrease the time to drastically but still slow)
I presume the script uses rubygems? (It'll say require "rubygems" if so)
You could try installing minigems (gem install minigems) and then use minigems instead of rubygems - should speed things up a little.
Sorry, but there is no way to compile a ruby script. What sort of stuff is this script loading/doing?
You're right, 30 seconds is quite long. Is this script making calls out to the web or databases that are very expensive? It's hard to believe that libraries would take so long to load
... I just noticed the comments and saw that you got it down to 1-4 seconds...that's very good, especially when coming down from 30. Other comments are right, please post the requires at the top of the script
I'm pretty keen to develop my first Ruby app, as my company has finally blessed its use internally.
In everything I've read about Ruby up to v1.8, there is never anything positive said about performance, but I've found nothing about version 1.9. The last figures I saw about 1.8 had it drastically slower than just about everything out there, so I'm hoping this was addressed in 1.9.
Has performance drastically improved? Are there some concrete things that can be done with Ruby apps (or things to avoid) to keep performance at the best possible level?
There are some benchmarks of 1.8 vs 1.9 at http://www.rubychan.de/share/yarv_speedups.html. Overall, it looks like 1.9 is a lot faster in most cases.
If scalability and performance are really important to you you can also check out Ruby Enterprise Edition. It's a custom implementation of the Ruby interpreter that's supposed to be much better about memory allocation and garbage collection. I haven't seen any objective metrics comparing it directly to JRuby, but all of the anectdotal evidence I've heard has been very very good.
This is from the same company that created Passenger (aka mod_rails) which you should definitely check out as a rails deployment solution if you decide not to go the JRuby route.
Matz ruby 1.8.6 is much slower when it comes to performance and 1.9 and JRuby do alot to speed it up. But the performance isn't such that it will prevent you from doing anything you want in a web application. There are many large Ruby on Rails sites that do just fine with the "slower interpreted" language. When you get to scaling out web apps there are many more pressing performance issues than the speed of the language you are writing it in.
I've actually heard really good things performance with about the JVM implementation, JRuby. Completly anecdotal, but perhaps worth looking into.
See also http://en.wikipedia.org/wiki/JRuby#Performance
Check out "Writing Efficient Ruby Code" from Addison Wesley Professional:
http://safari.oreilly.com/9780321540034
I found some very helpful and interesting insights in this short work. And if you sign up for the free 10-day trial you could read it for free. (It's 50 pages and the trial gets you (AFAIR) 100 page views.)
https://ssl.safaribooksonline.com/promo
I am not a Ruby programmer but I have been pretty tightly involved in a JRuby deployment lately and can thus draw some conclusions. Do not expect to much from JRuby's performance. In interpreted mode, it seems to be somewhere in the range of C Ruby. JIT mode might be faster, but only in theory. In practice, we tried JIT mode on Glassfish for a decently-sized Rails application on a medium-sized server (dual core, 8GB RAM). And the truth is, the JITting took so freakingly much time, that the server needed 20-30 minutes before it answered the first request. Memory usage was astronomic, profiling did not work because the whole system grinded to halt with a profiler attached.
Bottom line: JRuby has its merits (multithreading, solid platform, easy Java integration), but given that interpreted mode is the only mode that worked for us in practice, it may be expected to be no better performance-wise than C Ruby.
I'd second the recommendation of the use of Passenger - it makes deployment and management of Rails applications trivial