Build Speeds for Development are unreasonable, can we parallelize them or improve them further?

core
42

I did install verdaccio this way:

npm install -g verdaccio

npm set registry http://localhost:4873/

npm adduser --registry http://localhost:4873

This will create npm registry config file ~/.npmrc

registry=http://localhost:4873/
//localhost:4873/:_authToken="...."

Then start verdaccio in one terminal

verdaccio

And in another terminal build Meteor project

# If you have build script
./build-project.sh
# or alternatively with meteor command
meteor

Then you see on verdaccio terminal how it caches npm packages to harddisk.

If you need to sometime delete npm cache, when verdaccio is not running, deleting is done this way:

rm -rf ~/.npm
3 Likes
43

If you sometime want to not use verdaccio, you can rename .npmrc file, where npm registry address is:

# Change to your home directory
cd
# Rename npm registry file
mv .npmrc .npmrc-not-in-use
44

Have you considered using dynamic imports? As for NPM we use the NPM service now for easy, but in past we’ve poorly used a “machine-user” as github calls them (a fake/blank user) and OAUTH tokens.

45

This is a lot of work for something meteor should just handle, and it does, its as you said meteor will pull from disk if it has, but I’ve tested on nvme drives and build times were still the same. The issue is CPU bound, which is thread bound. Webpack has some loader which allow for transpiling in threads, even the Jest testing framework will run in threads. Meteor has to come forward and make use of threading and hide the complexity.

46

I’m still using Meteor 1.6.0.1 still with Wekan, because trying to upgrade newer Meteor https://github.com/wekan/wekan/issues/1522 downgrades coffeescript always when building with meteor command. I did not yet find a way to force specific dependency version, so all this magic in reality distortion field makes me wish for something like Django’s “removing the magic” or Rust’s “language ergonomics”. I am still very grateful about all that Meteor has made easy when maintaining Wekan, and look forward to upgrading for all the new Meteor features. Only way that I can think of to currently speed up builds is using bare metal server that has powerful CPU.

47

Much of the overhead is in maintaining the in-memory cache. On every reload it looks at every single file to see if it has changed. The actual FS system calls themselves are quite fast, but there is still CPU overhead and memory allocation on the Node side (in many apps, 40% of build times are garbage collection).

Running strace on the Meteor build process is quite interesting. Here is an strace summary for a client-only rebuild in our application:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 75.46    0.304715           0   1388261      6348 futex
  8.44    0.034100           0    234080        59 stat
  5.55    0.022430           0    154309           getdents
  3.53    0.014272           0     77150           openat
  2.34    0.009462           0     94314           rt_sigprocmask
  2.31    0.009318           0     81618           close
  1.42    0.005737           8       709           epoll_wait
  0.50    0.002025           0     26403      4296 lstat
  0.13    0.000541           0      4954       487 open
  0.12    0.000493          27        18           pwrite
  0.07    0.000277           0      4781           read
  0.04    0.000172           0      4449           fstat
  0.03    0.000123           0       345           mmap
  0.01    0.000043           0       122           munmap
  0.01    0.000029           1        40           madvise
  0.00    0.000015          15         1         1 connect
  0.00    0.000015           1        12         5 rmdir
  0.00    0.000015           2        10           unlink
  0.00    0.000012           1        20         1 rename
  0.00    0.000007           1        10           write
  0.00    0.000002           2         1           socket
  0.00    0.000002           0         7         1 epoll_ctl
  0.00    0.000002           1         4         1 inotify_rm_watch
  0.00    0.000001           0         3           recvmsg
  0.00    0.000001           1         2           uname
  0.00    0.000000           0         1           setsockopt
  0.00    0.000000           0         1           getsockopt
  0.00    0.000000           0         7           mkdir
  0.00    0.000000           0         3           readlink
  0.00    0.000000           0         4           inotify_add_watch
------ ----------- ----------- --------- --------- ----------------
100.00    0.403809               2071639     11199 total

Note the massive number of FS system calls. The time spent in the kernel level system call is negligible (which is what strace reports), but the Node-side overhead is large. Looking at an actual CPU profile of rebuilds (using https://github.com/qualialabs/profile) confirms this suspicion.

1 Like
48

Hopefully new Node v8.12 fill fix some of this, links to performance issues here

49

Yeah, in particular it’ll fix the crazy fiber switching issues. Will also really help production performance.

Here’s the PR https://github.com/nodejs/node/pull/21593

50

You are better off with an overclocked Desktop CPU as meteor needs single thread performance.

51

Hi Benjamin,
The recent beta version 1.7.1-beta.21 is doing a pretty decent work !
Thanks.

I was quiet deseperate as my build time was getting worse and the application built on meteor 1.7.0.3.
More than 1 minute, each time I was editing a react file in the import forlder.
Meteor server + legacy build, running each time, and taking so long.

Seems that is fixed now, and I can’t thank you more !
Big up.

3 Likes
52

Beta version 1.7.1-beta.21 rocks

53

Can’t wait for 1.7.1 … build times in dev are killing me. If I do a meteor reset, normally can schedule in a cup of coffee.

54

I’m working on large projects with Meteor and 1.7.0.3 we never have slow rebuild times, but then again we are very careful about how package.json looks so if you fill it with chromedriver or other stuff, even for “dev dependencies” be prepared to wait.

55

Are you developing mobile apps?

56

We only build React Native apps, no Cordova.

57

Even if you don’t have a lot of ram, meteor on a virtual machine with ubuntu+lubuntu will be faster and use less ram than native meteor on windows, at least with robust projects, so give it a try if you are on windows.

Even when using linux, my advice for developers/freelancers would be to just stay away from projects that use meteor. There should be a way to test/develop without compilation, recompiling while developing when you change a single byte on a single file that a modern browser like chrome can understand natively shouldn’t be a thing.

58

If the project is set up corrrectly, changing a front-end file, does not require the whole app to re-compile. :slight_smile:

1 Like
59

@danielocdh

Even when using linux, my advice for developers/freelancers would be to just stay away from projects that use meteor. There should be a way to test/develop without compilation, recompiling while developing when you change a single byte on a single file that a modern browser like chrome can understand natively shouldn’t be a thing.

What do you recommend using, instead of Meteor? What web frameworks do not have compilation?

60

what vikr00001 said, I probably kept receiving bad set up projects. Getting extremely slow meteor projects to work on and not finding a solution for it was the main reason I eventually decided to fully stop developing for work. Since then I do it as a hobby sometimes and simply use native js ES5/6, one time I used webpack and babel

61

@danielocdh

There was some version of Stylus dependency, that did build very slowly, because it had bug, where it did spend a lot of time in loop doing nothing important. That is why I converted my Stylus code to CSS:

Also, there has been fixes to Meteor to improve build time. When building with Meteor, it is possible to see Meteor profile, what time each dependency and step takes. Some dependency taking too much time can be a bug.

METEOR_PROFILE=100 meteor build .build --directory --platforms=web.browser
1 Like