Issue title: Does rails precompile slim templates?  Any way to
 Issue body: With my latest deployment I'm running out of memory, so looking for ways to move things before the unicorn fork (using preload_app = true)

Do you know if slim templates are precompiled?  How would I go about trying to do that and storing them into the "cache" if not?

Thanks for a great project!

 Comments: 
 Comment 0: Yes, the templates are precompiled to ruby code.This is done at the first invocation.

 Comment 1: **This is done as long as you're running in the production environment.

 Comment 2: Right - but invocation for each template isn't done before the fork right?  It's done when each method is called for the first time - so none of these would be stored in shared memory.

 Comment 3: Yes. Ask the Rails guys if you need a joshuaspencer@example.org. This is not a Slim question but depends only on the framework.

 Comment 4: No answer over there unfortunately. If I manually loop through my 
template names and call render would that store it in slim's global 
cache? Or where is the cache stored?

Slim38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Template.new('template.slim', optional_option_hash).render(scope)

So that'd involve me making a list of each template, along with "fake" 
arguments to call it with. How do I pass in the arguments (can 'scope' 
be a hash?)

Any idea how much space templates take up? My project is fairly large, 
but I have no idea how large the "compiled" templates would be...

Thanks,
Kevin

Daniel Mendler wrote:

> Yes. Ask the Rails guys if you need a joshuaspencer@example.org. This
> is not a Slim question but depends only on the framework.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/slim-template/slim/issues/416#issuecomment-19737161.

 Comment 5: also related to #321 

@inspire22   I think https://github.com/rails/rails/blob/master/actionpack/lib/action_view/template.rb is a starting point to you.

 Comment 6: Thanks!  Any idea how to hook into slim/tilt to log when a template is compiled, so I can see when I'm successful?

 Comment 7: sorry, I didn't dig into it that much

 Comment 8: besides, if you can't tell how much memory one template cache takes, why bothering with templates at all? One Ruby process/worker will give you at least 100 megs right off the bat. In practice a footprint will be around 160 megs. This is the cost that you pay for programmer happiness.

 Comment 9: Well, 60 megs per process \* 10 workers = real memory at some point.

It's vaguely driven by my web processes hitting swap now that I have 
another app.

If it's decently easy and reliable, it could be a good contribution back 
to rails - the 2.x series did have a preload_templates option for 
haml/erb, it just seems to have gotten lost along the way.

Kevin

Andrii Malyshko wrote:

> besides, if you can't tell how much memory one template cache takes,
> why bothering with templates at all? One Ruby process/worker will give
> you at least 100 megs right off the bat. In practice a footprint will
> be around 160 megs. This is the cost that you pay for programmer
> happiness.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/slim-template/slim/issues/416#issuecomment-19781706.

 Comment 10: > 60 megs per process \* 10 workers

You got me wrong, I mentioned only the minimum amount of consumed memory, it depends on how many gems in your Gemfile. Obviously, you have to start with a benchmark that will show, how much memory is taken by the templates.  Is it big enough to be comparable with 150-160megs that already consumed?

>  the 2.x series did have a preload_templates option for
> haml/erb

could you point out to exact code on rails/rails repository? I see only https://github.com/rails/rails/blob/2-3-stable/railties/environments/production.rb#L10, which is the same as template caching now.

 Comment 11: Good call vs. premature optimization, thanks.  Looks like my entire templates directory is only ~800k - not sure how much more space a compiled template would take, but probably not a ton.  I was able to lower my # of workers considerably and still meet the current throughput without any issue.  It may get slow if traffic increases greatly, but it's much better than swapping.  Thanks for your help :)

{'source': 'GithubIssues', 'repo_name_with_owner': 'slim-template/slim', 'issue_id': 15775253, 'repo_stars': 5140.0}