You're all wonderful- merry Christmas! <3
https://twitter.com/hone02/status/548131759762968576
Although with Matz an employee I'm sure they were well ahead of the curve. ;)
For 2.1.5
AVG: 18.02
MEDIAN: 18.11
MIN: 16.26
MAX: 19.6
For 2.2
AVG: 18.162~
MEDIAN: 15.23
MIN: 14.44 <- nice
MAX: 47.03 <- first run, wut?
It looks better, but I haven't profiled the app on Passenger yet to see how well it plays with the whole app.
So I think all of their patches need to go through the bug tracker.
Hope it helps!
As of Ruby 1.9, there's a pretty sensible solution to this in the language, and I haven't had any encoding problems in some time. I appreciate I might have missed something though!
When the Ruby team makes changes the attitude is generally 'deal with it'. Sure they still do point releases on older versions but only for security issues AFAIK.
Python moves forward it just does a poor job of dragging everyone with it.
However they complement this attitude by being a lot better at working with big 3rd party library developers and making sure they are on board. To the best of knowledge there has never been a Ruby release that was incompatible with RoR for any period of time. Compare to Python that jumped to python 3 without either numpy or Django on board.
rvm get stable
rvm install ruby-2.2.0
btw: anyone else thinks Rails was mentioned too much in the release note?
I think it's smart, and one of the big reasons Ruby seems to manage version-to-version transition so well. Just look at python 3 to see what happens when a language moves forwards without taking its biggest 3rd party libraries into account.
Vfork in most older systems is like fork except it doesn't deeply duplicate all process state immediately (file handles, memory, such), so it can be faster if all the app wants to do is fork/exec. (We had to implement both fork and vfork in minix 2.x in uni.^)
But according to SO, most OSes implement fork lazily, so there's not much point in using it when fork will be just as fast without any change.
If there were a slowly-performing platform that has a specific performance issue identified by profiling as caused by fork, then mature optimization could follow. Otherwise, it seems like adding LoC without a clear goal.
The Symbol GC sounds good. Maybe this will imply code can associated with classes and modules can be GCed and required anew once all objects are freed (live upgrade apps without restarts).
^ The first thing I did to the Minix codebase was set keyboard repeat rate to the fastest possible values. Everyone else seemed content to waste their life waiting for their editor and debugger to move at a snail's pace. Of course, no else had x86 asm / pc hw io experience.
For example, 'FooBarWidget @ Passenger 5 "Raptor" is a well-crafted, thoughtful achievement in terms of app servers.
2.2 Symbol GC also sounds great. I'm just not convinced there is enough innovation to make Ruby an order-of-magnitude faster, use less memory / return memory back to the system.
A less easily fixed change is that the following syntax no longer works the same as it did in previous versions of Ruby:
def foo(bar = bar)
def foo(bar = bar())
This allows you to symbolize external hash keys without fear of a DOS attack.
As for performance, I think we'll have to wait to hear from adventurous souls who use this, or who have been using the rc's.
Hopefully you've been using New Relic and can see how memory usage on your dynos changes.