Very Long Build Time (on file change)


Everytime I’m changing and saving one of my files, Meteor is building my application and refreshing my browser. That’s a good thing, except most of the time it takes too long. It can hang for a while on building specific local packages (1-2 minutes approx.) and sometimes after finishing it’s starting all over again.

It’s very annoying and can’t be ignored. Can you please suggest potential causes for long/iterative builds?

I’ve noticed this too, moreso after upgrading to 1.5+. I recently published a few packages we were using locally to Atmosphere just to speed things up. I’d say normal rebuild times for me are in the 10-15 second range, but would be at least double that when building even a single local package.

Looks like there is an open issue:

Another issue I have is that meteor picks up file changes BEFORE i can save ALL files (even if I do “save all”, it often reacts before the disk does.

And then that change doesn’t get picked up in later refreshes. (If I save each file individually, same thing - changes made during a meteor refresh won’t get picked up).

(An easy fix might just be to introduce a 1-second delay after change detection, before beginning to rebuild)

Are you experiencing this as well, by chance?

1 Like

Same here. Isn’t there an environment variable one can set to increase the timeout?

I recommend taking a look at this article, especially the first half. It’s got some tips on speeding up reloads.

I also recommend checking out Reval (code here). It can give you 100ms code reloads (without a browser refresh or server restart). The front-end reloads work best if you’re using Blaze and the back-end reloads work best for reloading Meteor methods and publications. As a bonus, you also get a really neat in-browser code editor :slight_smile:

@jamgold are you referring to METEOR_WATCH_POLLING_INTERVAL_MS?

Same here too. I have recently switched to using SSD, yet the build time is still really really slow. I’m on ubuntu 16.04, meteor 1.5.2 and using package-based architecture.

Below is the result of meteor profiling…

| (#88) Profiling: ProjectContext prepareProjectForBuild
| Preparing project
| ProjectContext prepareProjectForBuild…120,199 ms (1)
| ├─ _initializeCatalog…310 ms (1)
| │ └─ LocalCatalog#initialize…298 ms (1)
| │ └─ LocalCatalog#_loadLocalPackages…277 ms (1)
| │ ├─ PackageSource#initFromPackageDir 163 ms (20)
| │ └─ other LocalCatalog#_loadLocalPackages 113 ms
| ├─ _resolveConstraints 193 ms (1)
| ├─ _downloadMissingPackages…1,131 ms (1)
| │ ├─ Isopack.readMetadataFromDirectory 141 ms (185)
| │ └─ other _downloadMissingPackages 991 ms
| └─ _buildLocalPackages…118,559 ms (1)
| ├─ IsopackCache Load local isopack 203 ms (185)
| ├─ IsopackCache Build local isopack…994 ms (10)
| │ ├─ Isopack#saveToPath 156 ms (1)
| │ └─ other IsopackCache Build local isopack 692 ms
| └─ other _buildLocalPackages 117,362 ms
| Top leaves:
| other _buildLocalPackages…117,362 ms (1)
| other _downloadMissingPackages…991 ms (1)
| other IsopackCache Build local isopack…692 ms (10)
| other LocalCatalog#_loadLocalPackages…113 ms (1)
| (#88) Total: 120,199 ms (ProjectContext prepareProjectForBuild)
| Top leaves:
| other ClientTarget#minifyCss…1,189 ms (2)
| Target#minifyJs…812 ms (2)
| other PackageSourceBatch.computeJsOutputFilesMap…572 ms (2)
| CssTools.parseCss…489 ms (38)
| Babel.compile…427 ms (734)
| other plugin ecmascript…400 ms (2)
| CssTools.stringifyCss…354 ms (2)
| linker File#getPrelinkedOutput…354 ms (96)
| wrapped.fs.readFileSync…299 ms (671)
| other Target#_runCompilerPlugins…295 ms (3)
| sha1…260 ms (5662)
| other linker Module#getPrelinkedFiles…203 ms (2)
| ImportScanner#_getInstallPath…196 ms (4238)
| other PackageSourceBatch#_linkJS…184 ms (316)
| getPrelinkedFiles toStringWithSourceMap…177 ms (3)
| Isopack#getUnibuildAtArch…158 ms (15290)
| other plugin templating-compiler…130 ms (2)
| other Target#make…128 ms (3)
| files.rm_recursive…113 ms (406)
| other JsImage#write…106 ms (1)
| (#89) Total: 9,311 ms (Rebuild App)

Yes, that is the variable, thanks. Had it buried somewhere in a config file.

i’m seeing this issue on the meteor 1.5.2 also… in essence, the latest changes to the file are not picked up.

I use save all in Atom quite a bit also, so it took me some time to work out what was happening…

Do you know how you can set this variable when developing locally (on windows)?

If you’re using cmd.exe:


If you’re using PowerShell:


Ah thanks. Going back to the original question of very long build times, I’ve been getting insanely long build times as well - 15 to 20 minutes (if ever) and at the end of it, sometimes there is just a syntax error I have to fix! Tried out the Profiler mentioned in the post/article linked above. (I write this post 19 minutes into a build process…Going insane.)

The files.renameDirAlmostAtomically…439,759 ms (3) seems to be the main culprit for me- does anyone know what fundamenally causes this, or how to further address it - permanently?(I’ve noticed some changes recently in the 1.6 release…so the short term solution perhaps is just to wait for that…but I’m using 1.5.1 and wasn’t having this issue until recently. This issue pops up every month or two even while keeping my project updated over the past year…so not sure if there’s an underlying cause I can address by doing things differently myself.)
EDIT: Deleting the “local” folder in the project helps - cuts the rebuild time down by 75%. Still a couple of minutes- but manageable; however, don’t understand how it actually works still.

| (#2) Total: 67,639 ms (ProjectContext prepareProjectForBuild)
| (#3) Profiling: Build App
=> Meteor is available. Update this project with ‘meteor update’.
=> Started MongoDB.
Building the application
…then I get this:
| Top leaves:
| other files.renameDirAlmostAtomically…439,759 ms (3)
| files.rm_recursive…17,646 ms (6)
| files.readFile…14,442 ms (1840)
| files.stat…11,420 ms (38368)
| Babel.compile…10,933 ms (436)

please check :