Any tips on optimizing rebuild speeds?

[waldgeist]

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.)

[robfallows]

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.

[waldgeist]

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.

[veered]

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

[hwillson]

Clear the bundler-cache in your app folder (rm -rf .meteor/local/bundler-cache/). When this gets big it slows down rebuilds.

Quick note about the bundler-cache; as of Meteor 1.5, it should no longer grow to infinity! 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:

Adjusted bundler-cache saved file approach to remove out of date cache files.

[brucejo]

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

10X build speed improvement

With Meteor 1.5 I had noticed a couple of problems: Issues #8801, #8614, #8485 and #8803. The issues have been resolved for me with the fix defined in #8801 (copied below) and I am now seeing build speeds that are extraordinarily fast and I can now experience the work that @benjamn has put into the build performance without issues. Big thanks to bouchepat. Summary Environment: Windows 10 with Defender running Editor: Visual Studio Code Issues Defender was analyzing every file emitted by th…

[jorgeer]

using local packages

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.

[seba]

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

[waldgeist]

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.

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.

[waldgeist]

Yeah, I already saw your issue today.

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.

[seba]

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.

[waldgeist]

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.

[alawi]

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.

[juho]

Unfortunately, this is not an option for me. I am re-using most of my packages across different apps

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