Forum: Ruby on Rails Rails 4 assets:precompile very slow all time

1c6d58c67eaa67983cf020aeafb8b10f?d=identicon&s=25 unknown (Guest)
on 2013-10-23 08:15
(Received via mailing list)
Hi, If I good understand, Rails 4 compile only changed assets ? Like
gem turbo-sprockets-rails3 ? In this case, I don't understand why launch
2
times 'rake assets:precompile', take same time (~10min). Result a very
slow
deploy...
1c6d58c67eaa67983cf020aeafb8b10f?d=identicon&s=25 unknown (Guest)
on 2013-10-25 08:04
(Received via mailing list)
Any idea ? Just tell me if I understand the process

Le mardi 22 octobre 2013 10:20:34 UTC+2, oli...@eboutic.ch a crit :
A18064dfd890279bda648d3aa9dc963e?d=identicon&s=25 Alexander Selivanov (Guest)
on 2014-06-09 13:32
(Received via mailing list)
same trouble, any ideas?

пятница, 25 октября 2013 г., 12:02:25 UTC+6 пользователь
oli...@eboutic.ch
написал:
F50d3b02eee623a2172b58c09fe31c2c?d=identicon&s=25 mike2r (Guest)
on 2014-06-09 19:59
(Received via mailing list)
On Tuesday, October 22, 2013 4:20:34 AM UTC-4, oli...@eboutic.ch wrote:
>
> Hi, If I good understand, Rails 4 compile only changed assets ? Like
> gem turbo-sprockets-rails3 ? In this case, I don't understand why launch 2
> times 'rake assets:precompile', take same time (~10min). Result a very slow
> deploy...
>

Yes, in theory, that's the way it works.  There are a number of things
that
could be going on.

Your long compile time could be a number of issues.  I would start with
the
easiest which is corrupted caches.  Run the following:

rake assets:clean assets:clobber

This wipes everything out.  Now run rake assets:precompile.  This will
be a
long one since everything is being compiled.  After that, you should be
able to make a change and only the changed asset will be recompiled.

If you're still having long run times, you may need to clean things up.
 There are several suggestions I could make:

1)  I only include images in the asset pipeline that get used on every
page
or the majority of pages such as a logo, background for a header, etc.
 Images that only get used on one page I keep in public/images and refer
to
them statically.  The reason for this is that every image in the
app/assets/images directory gets fingerprinted and copied to
/public/assets.  The only advantage to this is that the images are
pre-loaded in the browser.  However, it pre-loads them on every page,
regardless of whether that page uses the images or not.  To me, this is
a
lot of overhead and for images that I use only on one page or in one
area I
don't run through the pipeline.

2) Watch your filenames.  Don't name a stylesheet mystylesheet.css.scss
if,
in fact, the file only contains only CSS and no SASS code in it.  It
will
unnecessarily get pre-processed when no pre-processing is required.
Same
goes for erb & coffee.

3)  This is a personal belief, a lot of developers would disagree, but I
don't ever use require_tree or require_directory in the manifest.
First,
with stylesheets, order is important so I need to require stylesheets in
the right order and second, I want to be sure that only stylesheets and
javascript I specifically require are included.

4) You may have issues with your deployment tool.  Capistrano, at one
point, was touching every asset causing the pipeline to completely
recompile regardless of whether changes had been made or not.  I believe
this was fixed, but I'm not positive.

Beyond this, I'm open for other's comments.  Hopefully, some of these
suggestions will help improve your times.
A47e0a6beeb9d048ff054fc1c3a97418?d=identicon&s=25 Walter Davis (walterdavis)
on 2014-06-09 20:13
(Received via mailing list)
On Jun 9, 2014, at 1:58 PM, mike2r wrote:

>
> 4) You may have issues with your deployment tool.  Capistrano, at one point, was
touching every asset causing the pipeline to completely recompile regardless of
whether changes had been made or not.  I believe this was fixed, but I'm not
positive.
>
> Beyond this, I'm open for other's comments.  Hopefully, some of these
suggestions will help improve your times.

I went through a phase on one server where my compile times would go up
and up until I restarted the server, then they would be blinding fast
again for a while, then get steadily worse. I don't remember changing
anything, but the behavior went away. Might have been an update to
nodejs from regular apt-get updates that did that. Which JavaScript
engine are you running on your server?

Walter
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.