Skip to content
This repository was archived by the owner on Dec 17, 2024. It is now read-only.

Slow startup time when minify is enabled #23

Open
aozora opened this issue Sep 24, 2012 · 8 comments
Open

Slow startup time when minify is enabled #23

aozora opened this issue Sep 24, 2012 · 8 comments

Comments

@aozora
Copy link

aozora commented Sep 24, 2012

I hosted my app that use bundle-Up on nodejitsu, mut if I enable the minifyCss & minifyJs options, the app start take over 20 seconds to start, and the hosting provider than reject my app.

Looking at the code, I see that in bundle.coffee you use a lot of SYNC file operations, maybe that is the cause to the slowness...
or maybe is another...

@Cowboy-coder
Copy link
Owner

Yes it is sync calls on startup in production because otherwise there is a risk that users receive assets that aren't really fully compiled yet. But yeah, 20 seconds sounds a bit too long for sure. How many css and js files do you have? Turning off minifyJS will for sure speed things up though.

@aozora
Copy link
Author

aozora commented Sep 24, 2012

there is very little of css & js to minify... you can see on www.marcellop.com.. for now it runs only with bundle enabled but minify disabled...

@Cowboy-coder
Copy link
Owner

Hm, yeah. Not much to do about it though. Right now we are using it for a site with like 15+ .coffee files and equally amount of .stylus files and it does maybe take 4-5 seconds in startup. We are only using the minifyCss:true-option though. You could try that. UglifyJS (used by minifyJs) takes some time to process I have noticed.

@gdibble
Copy link

gdibble commented Dec 16, 2012

I've set all my app templates to 'minifyJs = false' in production.
Would love to have it reliable and fast enough to process the JS and thus be able to enable js minification.
Think it may have anything to do with the UglifyJS2 update?

~Your time, thoughts and efforts are greatly appreciated; I really like this module :)

@zthomas
Copy link

zthomas commented Feb 10, 2013

For me, it's fine it takes a bit of time on the first startup, the problem is that bundle up runs the compilation even when the files haven't changed since last time. So if there was an uncaught error and the process dies and restarts, it would take forever to restart. What if instead of using a hash suffix to append to the generated bundled up files, we use a timestamp. Then on every node process restart we can check if the files have been modified since last compilation before we try to compile everything again. I think that would solve our problems.

@Cowboy-coder
Copy link
Owner

Yeah, that's a great idea.

@Cowboy-coder
Copy link
Owner

I will make a change for this!

What I will do is that I will only generate the files on first startup when bundle:true is set and the following times I will only take the .css and .js files in generated/bundle and load them in directly, without ever checking the assets file.

This have been a pain-point for us as well (we're also using bundle-up in production) since it simply isn't viable to have these long start up times. This might give unexpected results for you in production, depending on how you are managing your npm modules. I will release a new version (0.4.0) to npm with this change. You will need to make sure that generated/bundle either is nuked between deploys or that the files there are up-to-date. I will also release a separate executeable that will help out to generate these bundles at build-time (using Jenkins or whatever...)

@zthomas
Copy link

zthomas commented Jun 12, 2013

Awesome, thanks for responding. Look forward to the update :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants