Add bytecode cache to Ruby

by ksec • 11 years ago

75 46 11 years ago

3JPLW2• 11 years ago

What's the relationship between github/ruby and ruby/ruby? It looks like they've diverged quite a far ways away from each other, but that might just be an artifact of which branches GitHub uses when comparing the two.

randall• 11 years ago

Seems like this is Github's (the company's) fork of Ruby. ruby/ruby seems like the official ruby.

YorickPeterse• 11 years ago

Correct, Github uses their own fork to apply changes for their own needs.

claudiug2• 11 years ago

what is the advantages of adding bytecode cache?

Zash• 11 years ago

It lets you skip parsing of source code into bytecode if the sources have not changed.

cpr• 11 years ago

Same as for .pyc -- caches the result of parsing and translating the parse tree into bytecodes.

FooBarWidget• 11 years ago

In other words, faster loading times?

nnq• 11 years ago

speculating: it allows you to still be fine with a slower parser. and this means you can theoretically make the parser smarter (like make it do some inference and catch some bugs at parse-time?) without worrying that much about performance. but then again, I can't imagine what kind of bugs could a parser catch for such a dynamic language like Ruby, so they're probably just doing it to shave some milliseconds from program-start-up time...

btown• 11 years ago

With huge libraries (like SpreeCommerce, for instance), startup time can be seconds or more even on recent hardware, and the vast majority of that code isn't changing between runs. So if every gem was cached, they could see radically faster times to load their test suites across their entire organization. It's well worth it even without a smarter parser.

Arnor• 11 years ago

How significant is the performance impact on a mid-large Ruby on Rails application?

cheald2• 11 years ago

A bytecode cache is unlikely to affect runtime performance; only load times.

fizx• 11 years ago

It's mostly annoying in development when your mid-large Rails app takes 30s-2m to start-up and/or reload after an edit.

vidarh2• 11 years ago

Most of the time that is likely due to bundler/rubygems stuffing your load path full and causing thousands of unnecessary stat calls.

The actual time spent loading/parsing files is in most cases a tiny fraction of the startup time of any large project using rubygems and bundler.

I counted several hundred thousand unnecessary stat calls on the biggest app I have, and ended up with a ugly hack where we trimmed the load path around each set of require's to only paths needed by that specific gem.

Mojah• 11 years ago

This is the equivalent of APC or OpCache in PHP's world?

cheald2• 11 years ago

No, Ruby behaves like APC by default; code is loaded and parsed once per process, and then the AST is reused from memory. You can do some stuff to hot reload from disk (ie, Rails' reloader), but you have to intentionally do it.

This would just improve the time to initially start a Ruby process.

Freaky• 11 years ago

PHP needs an opcache because its standard behaviour is to discard all state after each request - including all compiled bytecode - kind of emulating the CGI model.

Ruby web apps on the other hand tend to be run in a loop - the script never exits after a request, it just goes back to the top of the loop to accept the next request to serve.

e.g. https://github.com/rack/rack/blob/master/lib/rack/handler/fa...

        FCGI.each { |request|
          serve request, app
        }

It's nice because it completely decouples your app's startup time from request processing time, so you can do expensive setup stuff up-front without slowing down each request. The disadvantage to that is there's not much pressure to keep startup time low, since it's only happening once.

juliangregorian• 11 years ago

Yeah man, PHP makes scaling easy, it's shared nothing by default, do you even web scale bro? /s

daurnimator3• 11 years ago

Interesting...

The Lua community has found that bytecode is actually slower to load than it is to generate from source: The extra latency of loading the (larger) bytecode from disk/ssd/flash, exceeds the cpu time to lex/parse.

ploxiln2• 11 years ago

On the other hand, Lua syntax is much simpler

(slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-par...)

daurnimator3• 11 years ago

slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-par...

Ouch.... Perhaps a lesson in making your language's grammar too complex: if you do, you'll eventually have to pre-compile.

mst• 11 years ago

I've seen similar results with perl bytecode.

Our syntax probably isn't simpler :)

haberman3• 11 years ago

I wrote a benchmark that measures just CPU impacts, and it finds that loading source code takes 25x longer: http://blog.reverberate.org/2014/10/the-speed-of-python-ruby...

daurnimator3• 11 years ago

A few things:

  - you don't drop the disk cache; so you're loading from RAM (echo 3 > /proc/sys/vm/drop_caches)
  - you don't have very complex code
  - you timing includes starting/loading the intepreter itself.

JulianWasTaken3• 11 years ago

Hah. .pyc files are one of the worst part of Python for developers.

export PYTHONDONTWRITEBYTECODE=true is the first thing anyone should be doing.

I guess it figures that we copy each others' mistakes.

michaelmior3• 11 years ago

I've been coding in Python for many years and I can count on one hand the number of times that this has actually caused me any problems.

JulianWasTaken3• 11 years ago

What is the total amount of time you spent during those few times, although including the amount of time to learn what happened, and how many thousands of times larger is that amount than the sum total of the time saved by caching bytecode compilation every single time you loaded a pyc for every file you ever wrote?

gerner• 11 years ago

can you be more specific?

robbles• 11 years ago

Refactoring a module to a package (e.g. mymodule.py -> mymodule/__init__.py) can cause errors if you don't clear the bytecode, since it can pick up mymodule.pyc and fail to see the new files.

Not sure about the exact conditions when this occurs, but it's definitely happened to me when code is refactored and you pull the newest version in with git.

aaronbrethorst• 11 years ago

Does anyone know, offhand (or have a good educated guess), on what the largest monolithic Ruby codebase in existence is? Is it GitHub?

ksec3• 11 years ago

Cookpad from Japan?

https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-...

50 million unique user / month 15,000 Req/Sec

I posted this awhile ago but didn't pulled much attention

https://news.ycombinator.com/item?id=9161220

haberman3• 11 years ago

I wrote a benchmark that measures the speed of various VM parsers and the speedup that precompiling brings. I found that precompiling was a huge speed benefit: http://blog.reverberate.org/2014/10/the-speed-of-python-ruby...

Add bytecode cache to Ruby

Related Stories