Symbol vs String performance
A more interesting metric to this discussion is the use of strings versus symbols. Fortunately, these types of discussions can easily be solved by benchmarks:
Results under Ruby 1.8.6:
user system total real less no op
String instanciation 9.050000 0.010000 9.060000 ( 9.057162) 5.921219
Symbol use 5.130000 0.000000 5.130000 ( 5.131844) 1.995901
new String#to_sym 14.550000 0.020000 14.570000 ( 14.567466) 11.431523
const String#to_sym 11.960000 0.010000 11.970000 ( 11.967217) 8.831274
String const lookup 6.350000 0.010000 6.360000 ( 6.358697) 3.222754
Symbol const lookup 6.400000 0.010000 6.410000 ( 6.416395) 3.280452
No op 3.130000 0.010000 3.140000 ( 3.135943) n/a
Results under Ruby 1.9.1:
user system total real less no op
String instanciation 9.170000 0.010000 9.180000 ( 9.174451) 4.736163
Symbol use 4.920000 0.010000 4.930000 ( 4.930031) 0.491743
new String#to_sym 18.080000 0.030000 18.110000 ( 18.087386) 13.649098
const String#to_sym 13.940000 0.030000 13.970000 ( 13.954099) 9.515811
String const lookup 4.920000 0.000000 4.920000 ( 4.927497) 0.489209
Symbol const lookup 4.910000 0.020000 4.930000 ( 4.921151) 0.482863
No op 4.440000 0.000000 4.440000 ( 4.438288) n/a
What do these results mean? Well, first you need to subtract out the “no op” results from all the others, which I’ve added as a column above. We can now see that string instantiation takes about 90 nanoseconds, which means about 11000 string instantiations per millisecond. Are symbols faster? Considerably so. But the real lesson here is that these numbers are so small that no one in there right mind should spend time worrying about them.
So please, use symbols when you should use symbols, and otherwise use strings.
Garbage collection thresholds in Ruby
I’ve put together a somewhat extensive collection of scripts and results from looking at how often objects get garbage collected in Ruby 1.8 and Ruby 1.9. Performance metrics are also provided running the script under various different environments, which I found quite fascinating. irb, for instance, is ridiculously slow. Granted, the vast majority of these scripts times are spent performing the very inefficient ObjectSpace calls, so the raw numbers should be taken with a grain of salt. The metrics are only interesting for comparison, and are of questionable use.
This was instigated by a String versus Symbol discussion in #ruby on Freenode. The individual was primarily worried about memory usage, and these scripts confirm that strings will get garbage collected often and quickly.
One thing to note is how Ruby 1.8 changes its thresholds for garbage collection under each environment, which may be based on the amount of objects in global space that it cannot garbage collect. Under Ruby 1.9, the results are bit more consistent, although this may be due to better metrics being available in Ruby 1.9.
Now shipping internationally
By popular demand, we’ve added shipping support for 32 additional countries to RubyRags:
Our full country list is: Argentina, Australia, Austria, Belgium, Brazil, Canada, Denmark, Finland, France, Germany, Hungary, Iceland, India, Ireland, Italy, Japan, Luxembourg, Malaysia, Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Russian Federation, Singapore, Slovakia, Spain, Sweden, Switzerland, UK, USA
If your country isn’t on the list, contact us and let us know of your dissent!
Remembering lighttpd, nginx, and the Internet as a pipe
We asked ourselves a year ago if lighttpd 1.5.0 was vaporware. It seems that was nearly true. At that time, nginx, apache’s mod_proxy_balancer, and haproxy were flourishing as Rails proxy solutions. The more recent introduction of Phusion Passenger (mod_rails) and Ruby Enterprise Edition, both excellent, free, and open-source products, has now driven most deployments (including our own) away from proxying altogether.
There is—or was—generally two counter-arguments to Passenger. The first is the stability and performance argument, which is well understood and has been discussed at length. I believed it was well summarized by Engine Yard’s discussion on the topic. But this is not the argument I’m not interested in.
My early argument against mod_rails was complexity: first, by using Apache instead of a smaller, simpler web server, and second, using a platform that I don’t comprehend and can’t debug. This argument relates to an old article I wrote: that Rails applications—and applications in general—should act like a pipe. (The original article, by James Duncan Davidson, is so old its only accessible through archive.org). My presumption was that the same argument should apply to a 3rd-party mod_rails solution: I don’t know anything about the app server, so if I have problems, I’m screwed. How is this better than FastCGI?
It is ironic, then, to note the success of Passenger in light of Rails’ history with FastCGI. The reason, as it turns out, basically comes down to two answers:
- Passenger is easy to set up under Apache, and requires less configuration than under nginx
- Passenger always works, in my experience, and thus debugging problems is non-existent.
- As a bonus, if you’re using something like monit to ensure your app stays up, monitoring apache2 is a lot easier than individual mongrel processes.
So, better products are better, and users (including myself) will flock to them once they realize it.
The Future
I do wonder, though, whether history will continue to repeat itself in this regard. Where will the next improvements be? What will be our theory (or justifications, as it seems to turn out) behind those improvements? Personally, I’ve been eying threaded solutions for a long time, and given that mod_rails is a multi-process solution, perhaps threads will move things forward in the future. However, given that Ruby 1.9 is still limited by the Global Interpreter Lock, we might not see a threaded answer for a while. The closest we’ll come in the short term is JRuby. Could it be possible that JRuby is the future? Only time will tell.
ls, colors, and Terminal.app
This isn’t a Ruby thing but many of us spend a lot of time in Terminal.app, and I suspect few of you have taken the time to both enable colors and change your LSCOLORS, the setting which affects what colors ls uses when in color mode.
Enable Colors in ls
In order for ls to use colors at all, you need to set up an alias to turn colors on. To do this, open (or create) .profile file in your home directory using your favorite text editor and add:
alias ls="ls -G"
Now open a new Terminal window and type ls. You will see colors, hurray!
Make Colors Linux-like
If you’re used to Linux-like colors, you will appreciate this setting. This is what I use and it works particularly well on dark Terminal backgrounds (I use the “Pro” theme). I also check off “Use bright colors for bold text” under Terminal > Preferences > Settings. Again, add this to your .profile:
export LSCOLORS="ExGxBxDxCxEgEdxbxgxcxd"
Customize Your Colors
The values in LSCOLORS are codes corresponding to different colors for different types of files. The letter you use indicates which color to use, and the position in the string indicates what type of file should be that color. Each color comes in pairs – a foreground color and a background color. Here is a list of color values:
- a = black
- b = red
- c = green
- d = brown
- e = blue
- f = magenta
- g = cyan
- h = grey
- A = dark grey
- B = bold red
- C = bold green
- D = yellow
- E = bold blue
- F = magenta
- G = cyan
- H = white
- x = default
And here is a list of the positions in LSCOLORS:
- directory
- symbolic link
- socket
- pipe
- executable
- block device
- character device
- executable with setuid set
- executable with setguid set
- directory writable by others, with sticky bit
- directory writable by others, without sticky bit
The default is “exfxcxdxbxegedabagacad”, which indicates blue foreground with default background for directories, magenta foreground with default background for symbolic links, etc.
Interview on the Ruby on Rails podcast.
The interview I did with the incredibly gracious and awesome Geoffrey Grosenbach (of Peepcasts) on the official Ruby on Rails podcast just went up.
I talk a little bit about consulting at Norbauer Inc, a bit about RubyRags, and I spend a bit of time kicking social networks in the nuts.
Incidentally, I’m proud to announce that we’re now selling Peepcode shirts at RubyRags:
Alternative Ruby Implementations
Sorry to just link drop on ya’ll, but if you haven’t seen it, Charles Nutter of the JRuby team has published a writeup titled Promise and Perils for Alternative Ruby Impls. It provides an excellent analysis of 1.8, 1.9, JRuby, Rubinius, and the other Ruby interpreter projects out there, if only slightly biased for JRuby (understandably). If you have an interest in the future of Ruby, it is a recommended read.
Rails 2.0 development finally meets Web 2.0
I know I am late to the show, but I’d just like to say it is about time that Rails move off of Trac – with the move to Lighthouse and Github, Rails development itself is now hosted on awesome Rails-based services. I know such migrations are not easy for such a large project so I just want to say thanks to the Rails team, and nice choices!
Strange analogy
Creating software is like eating a grapefruit (Randall Munroe’s favorite fruit). Sure, you can rush through it and you’ll get some enjoyment out of the grapefruit bits, but if you take your time and patience, you will get much more out of it. Like all things, you reap what you sow.
Gitsplosion
So Git has this charming habit of leaving directories intact when you use it to delete their content. If you try to delete, say, vendor/rails, it will therefore leave a barren ghost-town of EDGE directories intact.
This will cause the following, not-particularly-elucidating error whenever you try to do anything:
(in /Users/ryan/Sites/app_name)
rake aborted!
no such file to load -- /blah/blah/lib/initializer
/Users/ryan/Sites/app_name/rakefile:4
(See full trace by running task with --trace)
The solution is just a simple, friendly:
rm -rf vendor/rails
Then you’ll be able to freeze again, and whatnot.
UPDATE I have submitted a patch to Rails to make it less dumb about this (and actually check that Rails really exists rather than just checking for its directories.) If you think this is a worthwhile patch, please go put a +1 in the ticket comments.
Then once we can set it to “Verified,” maybe it’ll be accepted in three years, just in time for Git to be supplanted by some other new nerd bauble.
