Any tips on optimizing rebuild speeds?

The rebuild times of my app are getting painfully slow. This has a drastic impact on my overall productivity, especially if I compare it to my Webpack apps. I don’t expect magic, but any hints on improving / speeding up rebuild times is highly appreciated.

(I’m still on 1.5, since I have problems building my app on iOS with 1.6, but a quick test with 1.6 didn’t show any noticeable build improvements anyways.)

Three tips spring to mind:

  1. Clear the bundler-cache in your app folder (rm -rf .meteor/local/bundler-cache/). When this gets big it slows down rebuilds.
  2. Ensure you’ve completely segregated your client and server files (so client changes don’t cause server rebuilds and vice versa).
  3. Analyse where the pain points are by setting METEOR_PROFILE=100 (or any number: 100 means steps taking longer than 100ms will be reported) and looking at the output.
1 Like

Thanks for sharing your insights. Highly appreciated!

ad 1: I’m doing this regularly, also because it solves some weird problems with tap:i18n
ad 2: This is given in my app, because I am using local packages that clearly define which code goes where.
ad 3: Didn’t know about the profiling options, that’s cool. Will try it out.

1 Like

Check out https://github.com/qualialabs/reval. It’s especially helpful if you use Blaze, but it’ll still work on Meteor methods even if you don’t.

There’s also ways of doing more detailed profiling if METEOR_PROFILE isn’t working for you.

It’s a bit out-of-date, but this might also be helpful: https://medium.com/@lucashansen/faster-meteor-reloads-62cca5b56460

2 Likes

Quick note about the bundler-cache; as of Meteor 1.5, it should no longer grow to infinity! :slight_smile: As long as you’ve cleared out your old cache files at least once since updating to Meteor 1.5+ (or you’ve started a new app since Meteor 1.5), then you shouldn’t have to worry about the bundler-cache files anymore. For more info see:

1 Like

I have been enjoying blazingly fast rebuilds, it took me a while but this is the list of things I did:

  1. Put in SSD drives. Make sure that where your meteor tools and your meteor project are each hosted on an SSD. In my case I have a separate SSD for each.
  2. Make sure that any virus detection software is turned off for your development drive. Meteor produces 1000’s of files and if each one is getting checked by antivirus it really drags.
  3. Make sure your editor watcher is excluding your build directories, this can cause just as much of a slowdown as the antivirus

Getting and keeping these 3 things straight has really improved my build times significantly.

see

I know this is probably a non-solution for most people with large projects, but migrating our local packages to import modules drastically improved rebuild speeds.

I’m also seeing local packages as a major slowdown, I decided to track it down today and I seem to loose 10 seconds on every rebuild in the ‘prepareProjectForBuild’ step, because meteor is running npm on every file change inside a package: https://github.com/meteor/meteor/issues/9381

3 Likes

Unfortunately, this is not an option for me. I am re-using most of my packages across different apps, so I am heavily relying on Meteor’s packaging system (which is pretty cool, especially in combination with a central package repository). But I already feared that my high loading times might be somewhat related to using Meteor packages.

1 Like

Yeah, I already saw your issue today. :slight_smile:

But I wasn’t sure if I was actually affected by this, since I am not using Npm.depends() that much anymore. Main reason is that the npm packages are duplicated if they are referenced in more than one Meteor package this way.

Yeah, but I like packages being self-contained, stating their own dependencies.
Also if I recall correctly, globally installed babel modules don’t work for packages.

Anyway, I don’t know if having a lot or little matters that much. I think as soon as you have one you can loose quite a bit of time. But maybe your profile data shows something else. Might be interesting to post that since they’re very informative.

1 Like

Globally installed modules work pretty well for packages. That’s the way I am doing it at the moment, though I agree that a self-contained approach would be way more desirable.

I was planning to a split a relatively large code base to local packages in order to allow reuse across projects. Right now I have no noticeable build delay but it seems given this thread that I might introudce some by migrating to package based architecture.

Should I be concerned? It’s unfortunate because I’m finding meteor packaging system very interesting since it’s allowing me to slice the code base vertically and package a feature (components, pages, collections and api!) and reuse it in another project which is a huge productivity boost and cost saving.

You can just use a symlinked imports folder as well. Works fine for us coming from packages shared across apps.