
Bytecode cache is experimentally released in Ruby2.3 - remore
http://rimuru.lunanet.gr.jp/blog/cruby-bytecode-cache-is-experimentally-released
======
iheartmemcache
For those who missed it, a HN user is working full-time on dynamic
optimizations in Ruby (just finished his PhD thesis on it) -
[https://news.ycombinator.com/item?id=10791428](https://news.ycombinator.com/item?id=10791428)
\- It's showing significant (10x) speed-ups using real interesting
methodologies. He's working on it full-time as the project lead at Oracle now.
That thesis is worth a week-end read, it's something I would dedicate 4-6
lectures to if I was a professor.

~~~
cookrn
I believe the link you pointed to is for work specific to JRuby, while the OP
is specific to MRI.

------
pkmiec
This is definitely a nice improvement which can lead to Ruby performance
improvements.

It's also worth noting that Ruby 3 in general will have a focus on
performance. Matz talked about performance and the Ruby 3x3 effort during his
RubyKaigi keynote. The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster
than Ruby 2.

Full disclosure: I work for AppFolio which is helping to sponsor the Ruby 3x3
effort.

~~~
chrisseaton
Do you know if it has been decided where AppFolio is going to direct its
generous support yet? Are you hiring anyone?

I think the most realistic option is the idea of putting the LLVM bitcode of
MRI's functions into the MRI binary so that an LLVM JIT could optimise through
the core library. Evan Phoenix talked about this idea at Ruby Kaigi.

~~~
pkmiec
Yes, we are going to hire someone. We now have the position open and are
looking for candidates. We already have a couple of folks interested and we'd
like to get a few more so that we can find the best fit.

[0] [http://www.appfolioinc.com/jobs-
openings?p=job%2FoZ1c2fwY](http://www.appfolioinc.com/jobs-
openings?p=job%2FoZ1c2fwY) (it says Santa Barbara, CA but really anywhere in
the US is ok)

------
est
When is the last time you hear CPython performance objectives and
improvements?

I think the main problem of 2-3 transition is not the incompatibilities, but
lack of gain. If Py3k is 20% faster than Py2k it's a strong signal for mass
upgrading.

~~~
orf
Py3 is a lot faster than py2, read the release notes. In general though I
think the CPython team prefer a cleaner implementation than a confusing one
that's a bit faster. Just use PyPy

~~~
poooogles
Do you have a source for this performance that's not the release notes? In day
to day work I don't see much more than a 10% gains.

------
VeejayRampay
I like that there seems to be a lot of emphasis on performance for Ruby these
days. I know it's a hard subject to optimize for, especially in the case of
Ruby, but it's really appreciated.

------
pantulis
On the "Ruby Kaigi" presentation
([http://www.atdot.net/~ko1/activities/2015_RubyKaigi2015.pdf](http://www.atdot.net/~ko1/activities/2015_RubyKaigi2015.pdf)),
Koichi Sasada states that Matz doesn't like the automatic compilation of
source files a la Python, which automatically generates .pyc files.

Why is this? I understand the inconvenience of having lots of compiled files
in your deployment structure but I guess having a static compile phase would
be worse. Any opinions on this?

~~~
chrisseaton
I think Rubinius used to do it the python way (.rbc files in the same
directory) but I think it stopped (not the authority on that so may be wrong).

I think if you could do it transparently as a cache, and out of sight and
synchronised properly it would be fine, but writing files everywhere is not
ideal. Imagine two users running the same files but with different
configurations in the same directory at the same time. It's just a mess
waiting to happen.

Don't know if that's Rubinius' or Matz's problem with it though.

~~~
YorickPeterse
Rubinius stores the bytecode either in $PWD/.rbx or $HOME/.rbx depending on
which of the two exists. By default $HOME/.rbx is used.

 __EDIT __: I meant the default being $HOME /.rbx, not $PWD/.rbx

------
woodruffw
Great news! I just hope Ruby community won't be as recalcitrant as the Python
community about the 2-to-3 transition ;).

~~~
danso
The 1.8 to 1.9 transition was a significant hurdle, and virtually all of the
anecdotes I've heard from people who quit Ruby because of its purportedly bad
backwards compatibility were about 1.8->1.9. The cause of the difficulty was
similar: Unicode.

In any case, Ruby has/had a much different dynamic back then. Most developers
using Ruby were doing so because of Rails. When Rails made the move, _not_
switching would have been tech-debt-suicide for any stack depending on Rails
or library that was heavily associated with Rails.

I've just recently started using Python...and while there are a few big
players who still have SDKs in 2.x...I can't think of any single Python
library I've used that has had as much pull as RoR does on Ruby.

~~~
herbst
We have both in our company. And they stills struggle with Python 2 in many
cases because software just never got updated to 3 (but still is somewhat
active). While our Ruby team could just upgrade one after the other thing,
especially as most gems pretty soon supported 1.9 as well.

It is also worth mentioning that i still need to have Python 2 and 3 installed
to properly work on my Linux box. But i havent had needed a Ruby 1.8 since at
least 1.5 years now.

------
vinceyuan
It is actually "Do not parse and compile the files which have been parsed and
compiled. Use the cache.".

Can't believe it is done so late.

