Existem algumas poucas certezas na vida de um programador, uma delas é que o tempo de compilação tende sempre a ficar maior, conforme o projeto evolui, e para lidar com isso, precisamos de novas ferramentas ou novas formas de tratar o problema. Apesar de Ruby ser uma linguagem interpretada, todo programador Rails sofre, quando vai colocar o seu código no ar, com o tempo de compilação dos assets.

Nesse caso, o processo chamado mais precisamente de “precompile”, roda por padrão uma série de otimizações em códigos CSS e JavaScript, além da conversão de linguagens como SASS, LESS e CoffeScript, para as equivalente que seu browser é capas de entender.

Uma das coisas que mais me irritava nesse processo é que existia apenas uma única alternativa disponível no framework pra lidar com esse problema, trocar o “Componente” que realiza essa pré-compilação, por um possivelmente mais eficiente.

No entanto, nenhum existente foi pensado para ser executado em um conjunto grande de arquivos, e muito menos usando conceitos de paralelismo. E nesse ponto eu sempre achei que poderia ser algo que daria um ganho gigantesco no tempo de pré-compilação (considerando uma máquina com múltiplos cores).

Encontrei uma Gem que promete fazer algo a respeito nesse sentido. Ela faz um monkeypatch no Sprockets para que o mesmo utilize fork durante o processo e portanto, consiga utilizar todos os processadores da máquina, sem partir pra uma abordagem com threads.

Instalação:

As instruções de instalação, podem ser encontradas no projeto do Github: steel/sprockets-derailleur com a vantagem de também ter suporte para Rails 3.2

Bônus:

Existe uma discussão para melhorar o Sprockets sem a necessidade de se fazer um monkeypatch, se você também considera isso importante, contribua no ticket #308.

Bônus 2:

Eu presenciei uma melhora gigantesca no tempo de pré-compilação, quando atualizei uma aplicação legada que utilizava Rails 3.2 para 4.0 (caiu de 4 minutos para meros segundos). De início achei que pudesse ser um caso isolado e então conversei com algumas outras pessoas, que me relataram o mesmo resultado.

Então, se você está tendo problemas com isso e ainda está no Rails 3.2, mais um motivo para migrar logo.

Resultados:

Apenas para prova de conceito, escolhi uma aplicação OpenSource, para validar os ganhos. Estou utilizando o gitlabhq/gitlabhq, com a tag v7.1.0. Abaixo estão o antes e o depois (apesar de ser pouco o tempo de pré-compilação dessa aplicação, baixamos ~40%).

# Antes
bin/rake assets:precompile  0,10s user 0,02s system 1% cpu 9,124 total

# Depois
W, [2014-08-20T14:29:40.588648 #8941]  WARN -- : Initializing 8 workers
W, [2014-08-20T14:29:45.413547 #8941]  WARN -- : Completed compiling assets (5.29s)
bin/rake assets:precompile  0,10s user 0,02s system 2% cpu 5,829 total