[Solved] Build times unreasonably long

help
1

Hi all, thanks for reading.

Around 2 out of 3 rebuilds, the build time goes beyond 100 seconds, and seems to be related to the following builder steps in the profiler:

| Build App…100,758 ms (1)
| └─ files.withCache…100,758 ms (1)
| └─ bundler writeSiteArchive…94,120 ms (1)
| ├─ bundler writeTargetToPath…93,054 ms (2)
| │ ├─ Builder#complete…89,921 ms (2)
| │ │ └─ files.renameDirAlmostAtomically…89,921 ms (2)
| │ │ └─ files.rename 89,921 ms (4)

It takes around 89 seconds every time. The problem does not seem to occur when I delete myapp.meteor\local\build and myapp.meteor\local\bundler-cache.

I’m on windows 10 and the issue happens on every meteor release I’ve tried.

Any help would be greatly appreciated, this is really slowing my development.

Thanks!

2

Take a look at this and see if it helps.

I have been seeing really fast rebuilds since I sorted that out.

2 Likes
3

Thanks for your answer brucejo, I made some exclusions to Defender and it seems to fix it but let’s wait a bit, I’ll confirm whether the problem has completely disappeared when I’m sure it did :slight_smile: knocking on wood

4

I know you said you tried multiple versions of Meteor, but 1.5.2.1 -> 1.5.2.2 really helped the times for me.

5

It happened with both of these versions :slight_smile:

1 Like
6

Also, try shutting down your editor while the build is happening. If you see an improvement then you should make sure the editor has a watcher exclusion for .meteor\local.

7

I am using Atom. Not sure if it has a watcher, what do you think?

8

dunno.

Try shutting down atom and doing a build. If the build is noticeably faster, then it is likely atom has some sort of watcher.

Or with Atom up, do a build. Look at the Task Manager sorted by CPU usage. If you see some Atom processes getting busy during a build, then it is likely there is a watcher.

9

I believe Atom uses your .gitignore to determine which files to watch. So it should be excluding .meteor/local. Definitely check to make sure

10

Ok so I’ve been working for 45min an the problem hasn’t occured anymore. It seems the Windows Defender exceptions solved it ! I now experience quick rebuilds every time.

Atom did not seem to have any influence on the issue.

I added my application folder and node to exceptions.

Thanks a million !

1 Like
11

Ok so unfortunately I spoke too fast and the problem hasn’t been completely solved.

It seems to occur far less often but still does from time to time.

I will do some more tests and come post back.

12

So it’s been a day now and I can safely that the issue has indeed disappeared. My build times are now fast every time.

The reason why I hesitated was because another symptom arised; the builder seems to freeze and crash every 10 rebuilds or so, and gets stuck on “building for os…” forever, at which point I need to terminate and restart.

I know this is a different issue, but where should I be looking ? Is there a log or something somewhere that I can check out ?

13

Check out the METEOR_PROFILE flag.

14

Hi again,

So the windows defender exception might have helped since I have quick rebuilds most of the time now.

There’s probably another issue since the build sometimes gets back to 90 seconds with the same symptom as above in the profiler (always 89 seconds for files.rename), the only difference being that it happens less often now (around 1 time every 5-10 rebuilds instead of almost every time).

I added every possible folder and node to exceptions in windows defender. I also tried disabling real time protection altogether. My gitignore ignores the build folder too. Not sure where I should look next :frowning: any idea would be much appreciated.

15

I believe I found the culprit in windows’ Search Indexer. My folder was on the desktop which is being indexed, so the solution is either to move it to a non indexed area or to edit the indexation options of windows to exclude the folder.

Haven’t had a long build time since !

1 Like
16

@malekity, Good catch!