config.assets.compile=true in Rails production, why not?

I wrote that bit of the guide.

You definitely do not want to live compile in production.

When you have compile on, this is what happens:

Every request for a file in /assets is passed to Sprockets. On the first request for each and every asset it is compiled and cached in whatever Rails is using for cache (usually the filesystem).

On subsequent requests Sprockets receives the request and has to look up the fingerprinted filename, check that the file (image) or files(css and js) that make up the asset were not modified, and then if there is a cached version serve that.

That is everything in the assets folder and in any vendor/assets folders used by plugins.

That is a lot of overhead as, to be honest, the code is not optimized for speed.

This will have an impact on how fast asset go over the wire to the client, and will negatively impact the page load times of your site.

Compare with the default:

When assets are precompiled and compile is off, assets are compiled and fingerprinted to the public/assets. Sprockets returns a mapping table of the plain to fingerprinted filenames to Rails, and Rails writes this to the filesystem. The manifest file (YML in Rails 3 or JSON with a randomised name in Rails 4) is loaded into Memory by Rails at startup and cached for use by the asset helper methods.

This makes the generation of pages with the correct fingerprinted assets very fast, and the serving of the files themselves are web-server-from-the-filesystem fast. Both dramatically faster than live compiling.

To get the maximum advantage of the pipeline and fingerprinting, you need to set far-future headers on your web server, and enable gzip compression for js and css files. Sprockets writes gzipped versions of assets which you can set your server to use, removing the need for it to do so for each request.

This get assets out to the client as

From the official guide:

On the first request the assets are compiled and cached as outlined in development above, and the manifest names used in the helpers are altered to include the MD5 hash.

Sprockets also sets the Cache-Control HTTP header to max-age=31536000. This signals all caches between your server and the client browser that this content (the file served) can be cached for 1 year. The effect of this is to reduce the number of requests for this asset from your server; the asset has a good chance of being in the local browser cache or some intermediate cache.

This mode uses more memory, performs poorer than the default and is not recommended.

Also, precompile step is not trouble at all if you use Capistrano for your deploys. It takes care of it for you. You just run

cap deploy

or (depending on your setup)

cap production deploy

and you're all set. If you still don't use it, I highly recommend checking it out.