ionic-app-scripts 🚀 - Watching is slow

Please see https://github.com/driftyco/ionic-app-scripts/pull/44

This should ease up the watches memory usage and speed it up a bit.

mhartington on 30 Sep 2016

I'm not sure about that as it seems to fix the issue where multiple instances are running concurrently, but my watch is this slow even when I save a single change (thus only creating a single instance).

I'll be sure to report back when #44 is merged!

Manduro on 30 Sep 2016

Closed via https://github.com/driftyco/ionic-app-scripts/pull/44

This should be fixed in the next release of app scripts.

mhartington on 30 Sep 2016

Even with the above fix and ionic-app-scripts 0.0.27, it takes ~4 seconds for TS to compile in watch and ~8 seconds to bundle my project, in general it takes about ~15 seconds to reload. With the previous browserify + gulp build chain it took only 2 seconds. Is there any way to speed this up?

Kobzol on 2 Oct 2016

👍3

@mhartington Speed has definitely not changed with the new version. I'm still at 25-30 seconds for a watch reload and ~50 seconds for the initial build. Gulp did it in about 3 seconds for the same project.

Manduro on 2 Oct 2016

👍4

@mhartington, I agree with @Manduro and @Kobzol that this issue is not related to #44 and should be re-opened. The slowness does not seem to be related to a bug, but rather the bundling, AoT compilation and tree shaking performed by the introduction of Rollup. These steps slow down livereloading substantially. You are adding 15-30 seconds to the build time to shave less than a second off browser load time, and it doesn't make sense to do that for a build that is going to be loaded only once before being overwritten by the next small change.

I think the ideal solution would be to provide a "fast build" config option that skips these optimizations (AoT Compilation, tree shaking) and is tuned to provide the shortest wait between the start of the build and completion of the browser reload, and ionic serve should use that configuration. Hopefully that will bring us back to the super-fast reloads we were enjoying with previous beta releases.

jaufgang on 2 Oct 2016

👍11

Hi, unfortunately I must confirm that this is a huge problem. In beta11, with no AoT and rollup live reload was working great, just few seconds and changes were compiled to the script. Now, with the application that contains lots of .ts files and dependencies it takes almost 40-50 seconds to build .js output file (about 10-15sec for typescript compilation and 30-40 sec for bundle).

@mhartington, @manucorporat please reopen.

MarkChrisLevy on 3 Oct 2016

👍9

@mhartington Thanks for reopen. Below some logs from npm run watch:

-- initial build --
[15:31:10] ionic-app-scripts 0.0.27
[15:31:10] watch started ...
[15:31:10] build dev started ...
[15:31:10] clean started ...
[15:31:11] clean finished in 473 ms
[15:31:11] copy started ...
[15:31:11] typescript compiler started ...
[15:31:11] lint started ...
[15:31:12] copy finished in 1.50 s
[15:31:14] lint finished in 2.87 s
[15:31:33] typescript compiler ready in 21.70 s
[15:31:33] bundle dev started ...
[15:31:58] bundle dev finished in 25.76 s
[15:31:58] sass started ...
[15:32:02] sass finished in 3.97 s
[15:32:02] build dev finished in 51.91 s
[15:32:02] watch ready in 52.11 s

-- after one letter change in .ts file --
[15:34:40] typescript compilation started ...
[15:34:55] typescript compilation finished in 14.31 s
[15:34:56] bundle dev update started ...
[15:35:12] bundle dev update finished in 16.06 s
[15:35:12] sass started ...
[15:35:12] sass finished in 28 ms

As you can see it takes about 30 seconds to build new main.js. It seems, that there is an issue with typescript 2.0, cause it shouldn't take 14 seconds to compile one changed file - I've reported that as well https://github.com/Microsoft/TypeScript/issues/10018#issuecomment-251113388. The other issue is rollup, which takes 16 seconds.

MarkChrisLevy on 3 Oct 2016

👍1

I have same issues as described early by other colleagues. For example:

[20:13:47] typescript compilation started ...
[20:13:50] typescript compilation finished in 3.05 s
[20:13:50] bundle dev update started ...
JS changed: www/build/main.js
[20:14:03] bundle dev update finished in 12.72 s
[20:14:03] sass started ...
[20:14:03] sass finished in 53 ms

With beta.11 i had watch timing between 1-2.5 s.

maxkunitsa on 3 Oct 2016

I would like to point out that tslint also slows down the build by a few seconds. TSLint is a handy tool and its a great idea to use it when doing a full build, but it is a processing step that I would want to exclude when doing livereload/ionic serve. It's not contributing as much to the slowness as the AoT compilation and tree-shaking, but if a speed-optimized build configuration is being worked on, tslint should be excluded as well.

jaufgang on 4 Oct 2016

@jaufgang Also, considering most of our editors will be linting as we code, it's mostly superfluous during each watch build.

How about a --no-lint flag?

WhatsThatItsPat on 4 Oct 2016

i think a fully robust solution would have options to allow you to turn on/off individual build steps like tslint/AoT/tree-shaking via a project config file will different named build configurations, allow you to override those config file settings with command line switches, provide out of the box build configurations for production (slow build, fully optimized output) and dev (fast build, no optimizations)

right now, I'd be happy with _any_ means to speed up livereloading, even some advice on how to hack the app-scripts config files to speed things up while we are waiting for this issue to be addressed in a future release.

jaufgang on 4 Oct 2016

👍3

In version 0.0.29 some steps in 'ionic serve' was disabled, but still watch in 5 times slower then was previously with gulp. Example:

[09:18:02] bundle dev update started ...
JS changed: www/build/main.js
[09:18:12] bundle dev update finished in 9.72 s
[09:18:12] sass started ...
[09:18:12] sass finished in 16 ms

maxkunitsa on 6 Oct 2016

I'm also having the same issue. It takes like 20 seconds for livereload to reload browser tab even if I simply change a variable value. Gulp was almost instant. It is extremely slow compared to Gulp.

Aristona on 6 Oct 2016

I just want to add something here.

To the folks who are saying "Gulp was fast and instant", take note that gulp was also doing much less compared to what the build process is doing now.

It's not a fair comparison to make when you consider everything that is going on underneath.
https://github.com/driftyco/ionic-app-scripts#config-defaults

We're iterating quickly and have simplified the watch setup so we can do a bit less. 0.29 is out which has this in there. Also, changing up the npm scripts to match whats in the app base helps keep things up to date.

  "scripts": {
    "build": "ionic-app-scripts build",
    "watch": "ionic-app-scripts watch",
    "serve:before": "watch",
    "emulate:before": "build",
    "deploy:before": "build",
    "build:before": "build",
    "run:before": "build"
  },

mhartington on 6 Oct 2016

It's clear that tree shaking, rollup bundling, AOT compilation etc. for production takes much more time than before (with gulp), but the problem is that the dev version is much slower than before. It seems that the TypeScript regression that slowed it down (https://github.com/Microsoft/TypeScript/issues/10018#issuecomment-251113388) will be fixed in the next TS release, what about rollup, is there something that can be done about it to speed it up in dev build (for example turn off tree shaking)?

Kobzol on 6 Oct 2016

👍2

...or even take rollup out of the build altogether for dev builds? Really for dev builds, particularly when using watch/livereload, the only steps that are necessary are compile, concatenate and copy. That's it. Switching from gulp to npm scripts is fine, incorporating rollup and all of those other steps for production builds is great. But for dev builds, anything that slows down the time between start of compilation and viewing the changes in the app or browser is just an annoyance.

@mhartington, you say its not a fair comparison because of everything going on underneath, but that misses the point that all of that extra processing doesn't add value for a dev build.

Why can't you simply create a dev build configuration using the new npm scripts that is functionally equivalent to the previous gulp implementation (compile, concatenate, copy) and keep all of these additional build steps (jslint, AoT compilation, rollup bundling, etc) for production builds?

jaufgang on 6 Oct 2016

👍13

Hello everyone! We are consistently working on getting our dev builds faster, and you will see improvement on this in the future. I would just like to clarify that the watch task, which runs when running ionic serve does not do AOT compilation, only our prod build (when running ionic run, ionic build or ionic emulate ) does AOT compilation. Thanks!

jgw96 on 6 Oct 2016

@ionic/app-scripts": "0.0.23" did work with "allowJs": true but "0.0.29" resulting now in SyntaxError: Unexpected character '@'

tmvnk on 7 Oct 2016

@jaufgang I'm asking myself the same questions. I would add to your point, another question. I saw that with webpack is possible to do hot module reloading (see https://github.com/AngularClass/angular2-webpack-starter). Using rollup we will miss this feature, correct? @adamdbradley

marcoturi on 7 Oct 2016

👍1

I totally agree with @jaufgang. I really appreciate work of whole Ionic team (you guys are great!!), but if dev builds will be much slower than it was before rc, then part of the awesomeness of Ionic will be gone. @mhartington IMHO if it is not possible to optimize rollup (as it seems that is the issue) then going back to browserify is an option to think about. Still I so appreciate your amazing job!!! Thanks and no offense ;)

MarkChrisLevy on 7 Oct 2016

I'd just like to add another data point from my side (new to Ionic and busy going through various v2 tutorials): there definitely seems to be something strange happening with watch. I'm using ionic serve, and after a couple of code changes, the rebuild was taking around 80 seconds (on a very decent PC). Strangely, restarting ionic serve (and waiting for the app to come up) was faster than 80 seconds, around 20 in total.

ionic-watch

Above is a screenshot of the console logs from the 80s watch rebuild. At first glance (from the timestamps and durations), it seems like multiple of these 'dev bundle update' are running in parallel, since the logs from 14:00:39 seem to start on 13:59:20. Perhaps this type of thing is causing some locks / delays?

After a restart of ionic serve, rebuilds seem to be taking around 15s.

danielbarla on 8 Oct 2016

Just a quick follow up to my comment above, after another few days of general usage: the dev bundle / template update times seem to progressively get worse as time goes on. Very roughly, every change seems to add ~2 seconds to the total rebuild time, which very quickly adds up. E.g. on my system when ionic serve is first started, builds take about 12 seconds. After 10 to 20 changes, it's in the 30 - 40 seconds range, which is "reset" when ionic serve is restarted.

The important part is that this seems to be unrelated to what exactly is going on with the build (AOT optimizations, etc), it just gets slower and slower with use, even if you just add and delete a space for each rebuild.

On a side note, congrats to the team on Ionic, it's really an awesome framework so far.

danielbarla on 10 Oct 2016

when I development some time it take over 100 second for build
but it have good performance when it run on phone.
I hope we can fix this issue soon.

windwp on 10 Oct 2016

or even take rollup out of the build altogether for dev builds

I agree with this sentiment. I feel this is equivalent to Angular 2's process, during development you run npm start which simply runs the typescript watcher, compiling to the necessary javascript files, with a lightweight http server running in the background to serve them up. True, they currently advocate SystemJS but the same is possible for webpack.

I feel that trying to shoehorn the same process for development and production is fundamentally the wrong approach. They are very different things, with different requirements. What would be great is seeing fast compilation/reloading in the browser during development/watch mode, and fully optimised builds for production, which will necessitate longer compilation times. If this can be achieved with rollup, then great, but if not then another solution might be better - personally I've had lots of success with the webpack dev server.

fiznool on 13 Oct 2016

👍3

Report on 0.0.33:

Initial start:
watch ready in 48.00 s

SASS file change:
sass update finished in 4.74 s

HTML file change:
template update finished in 131 ms (Amazing!!)

TS file change:
transpile update finished in 6.71 s
bundle update finished in 32.92 s

So HTML updates have definitely improved by now, but the TS livereload still takes as long as on the initial app-scripts release.

Manduro on 14 Oct 2016

Same issue here

[11:36:33] bundle dev update finished in 26.42 s
[11:36:33] sass started ...
[11:36:33] sass finished in 57 ms
JS changed: www/build/main.js
[11:40:38] templateUpdate started ...
[11:40:38] bundle dev update started ...
JS changed: www/build/main.js
[11:40:55] bundle dev update finished in 17.09 s
[11:40:55] templateUpdate finished in 17.10 s

Any updates on this ? I get rollup does more than gulp, but can't we just use gulp for development and have rollup for builds?

realappie on 14 Oct 2016

HTML template rebuilds have drastically improved in the latest release. Additionally, we're adding webpack as the default bundler, with rollup as an option.

However, many of these numbers being reported is not apart of app-scripts control, such as the time it takes to compile TypeScript, and the time it takes for NGC to do Ahead of Time compiling. Also, AoT only happens on production builds, not dev buidls.

Also, in the more recently releases, tslint and sass runs in another core. The other idea of letting system do the bundling, or all the above.

We'll continue to improve the build process and we'll keep this open to discuss various ideas. But one thing to point out is that there is not easy answer at the moment since Angular's change to using @NgModule. So it's not that there was a regression since beta11, but that there are new requirements which made building apps more difficult. On just the basic starter app, I saw startup times around 1300 milliseconds in production for beta11. Since our new bundling system, startup times are an entire second faster for the exact same code. So while the dev builds times aren't the fastest right now, and we've got room for improvement, your users and their app experience is lightning fast because of these build tasks.

But I completely understand, and we'll keep improving build times with new ideas. Thanks

adamdbradley on 15 Oct 2016

Got the same issue, i already updated script to version 0.0.36

[17:30:31]  transpile update started ...
[17:30:36]  transpile update finished in 4.60 s
[17:30:36]  bundle update started ...
JS changed:   www/build/main.js
[17:30:55]  bundle update finished in 19.05 s
[17:30:55]  watch ready

zjhiphop on 16 Oct 2016

Timings are those. In fact mine are slower, in the future we might expect improvements in the performance. But but build process has become quite complex.

devarg on 16 Oct 2016

@adamdbradley Is webpack already the default bundler? Im on a v0.0.36 with rollup still as default.

realappie on 17 Oct 2016

@realappie With the latest release of app-scripts Rollup is still the default bundler. We are working hard on wrapping up some final issues with our webpack integration and hope to have it ready for testing asap. Thanks!

jgw96 on 17 Oct 2016

These are my bundle times right now

[15:01:40] watch ready
[15:01:41] transpile update started ...
[15:01:45] transpile update finished in 3.33 s
[15:01:45] bundle update started ...
JS changed: wwwbuildmain.js
[15:02:14] bundle update finished in 28.93 s
[15:02:14] watch ready
[15:02:14] transpile update started ...
[15:02:21] transpile update finished in 7.44 s
[15:02:21] bundle update started ...
JS changed: wwwbuildmain.js
[15:03:02] bundle update finished in 40.55 s
[15:03:02] watch ready

When should we expect for an improvement? Right now it's impossible for me to work. And this is only with couple of pages.

raducostea on 18 Oct 2016

@raducostea I understand what you talk about. As for templates, timings are acceptable, bundling is a little bit slower, for *.ts files is around 30 sec tops, maybe I shouldn't... but I got used to it, and spend that time thinking on good ideas ;) or reading the docs. When I need to make a lot of changes I stop the build process, make edits and restart ionic serve. My rc1 app now has a couple of dozens of views and build process doesn't get noticeable slower than with a couple of views. Don't panic, just hang a bit, things will get better, I suffered a lot the transition from beta11 to rc0 and r0 to rc1 with app-scripts 0.0.30 and timings were about 70 secs, so I'm pretty happy about 20-30 they have achieved in dev mode with 0.0.36

I also spend the dead time trying to add issues here and and share things on the blog, seriously, ionic team has proven to be SUPER receptive, and they make gold improvements with your support and detailed feedback.

devarg on 18 Oct 2016

😕1

I created a simple ionic2-webpack2-starter project. Using the webpack-dev-server there, reloading the page after each typescript code change takes 800-900ms. In comparison ionic serve with @ionic/[email protected] takes about 5 seconds at every change on my machine.

mirkonasato on 21 Oct 2016

🎉4 👍4

I had 5-7 seconds ionic serve with @ionic/[email protected] and after update to @ionic/[email protected] with rollup i had !!15-20 seconds, webpack not working at all
After decreasing version to @ionic/[email protected] i at least got 5-7 seconds again.

maxkunitsa on 31 Oct 2016

😕1

@maxkunitsa,

That's weird. Have you tried version 0.0.39? I consistently see builds done in 2.5 or less seconds. Webpack should be a lot faster than Rollup. Can you add the --debug flag to the end of the watch script in the package.json and see if there is any strange output?

Thanks,
Dan

danbucholtz on 1 Nov 2016

I agree, 0.0.39 works a lot better.

[18:27:26] build update started ...
[18:27:26] transpile update started ...
[18:27:27] transpile update finished in 512 ms
[18:27:27] webpack update started ...
[18:27:29] webpack update finished in 2.02 s
[18:27:29] build update finished in 2.53 s
[18:27:29] watch ready

raducostea on 1 Nov 2016

My build times vary a lot on 0.0.39, but on average it has definitely improved. I'm getting between ~5 and ~25 seconds. HTML updates are generally below ~15 seconds.

Manduro on 1 Nov 2016

@danbucholtz tnx for reply. I updated to 0.0.39 and got such results with rollup:

ionic $ [19:24:56]  template update started ...
JS changed:   www/build/main.js
[19:24:56]  template update finished in 99 ms 
[19:24:56]  watch ready 
[19:25:01]  template update started ... 
[19:25:01]  template update finished in 105 ms 
[19:25:01]  watch ready 
JS changed:   www/build/main.js
[19:25:07]  build update started ... 
[19:25:07]  transpile update started ... 
[19:25:08]  transpile update finished in 749 ms 
[19:25:08]  rollup update started ... 
JS changed:   www/build/main.js
[19:25:25]  rollup update finished in 17.02 s 
[19:25:25]  build update finished in 17.77 s 
[19:25:25]  watch ready 
[19:25:37]  build update started ... 
[19:25:37]  transpile update started ... 
[19:25:37]  transpile update finished in 386 ms 
[19:25:37]  rollup update started ... 
JS changed:   www/build/main.js
[19:25:51]  rollup update finished in 14.15 s 
[19:25:51]  build update finished in 14.54 s 
[19:25:51]  watch ready 
[19:25:55]  build update started ... 
[19:25:55]  transpile update started ... 
[19:25:55]  transpile update finished in 619 ms 
[19:25:55]  rollup update started ... 
JS changed:   www/build/main.js
[19:26:11]  rollup update finished in 15.70 s 
[19:26:11]  build update finished in 16.32 s 
[19:26:11]  watch ready

And with --debug

watch callback start, id: 0, isProd: false, event: change, path: 
            /Users/maksymkunytsia/work/paymash/pos/src/pages/settings/settings.page.ts MEM: 499.1MB 
[19:28:48]  build update started ... MEM: 499.1MB 
[19:28:48]  transpile update started ... MEM: 499.1MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 9875 MEM: 499.1MB 
[ DEBUG! ]  worker created, taskModule: transpile, pid: 9880 MEM: 499.9MB 
[19:28:48]  transpile update finished in 523 ms MEM: 499.9MB 
[19:28:48]  rollup update started ... MEM: 499.9MB 
[ DEBUG! ]  entry: /Users/maksymkunytsia/work/paymash/pos/src/app/main.dev.ts, dest: 
            /Users/maksymkunytsia/work/paymash/pos/www/build/main.js, cache: undefined, format: iife MEM: 500.0MB 
[ DEBUG! ]  worker exited, taskModule: lint, pid: 9875 MEM: 676.0MB 
[ DEBUG! ]  worker exited, taskModule: transpile, pid: 9880 MEM: 733.2MB 
[ DEBUG! ]  bundle.modules: 850 MEM: 812.1MB 
[ DEBUG! ]  Cached module paths: 850, 
            /var/folders/n8/9_st8r097wj6zm06r84gy0lr0000gn/T/usersmaksymkunytsiaworkpaymashpos/modulepaths.json MEM: 
            812.1MB 
JS changed:   www/build/main.js
[19:29:02]  rollup update finished in 13.93 s MEM: 1125.1MB 
[19:29:02]  build update finished in 14.47 s MEM: 1125.1MB 
[ DEBUG! ]  watch callback complete, id: 0, isProd: false, event: change, path: 
            /Users/maksymkunytsia/work/paymash/pos/src/pages/settings/settings.page.ts MEM: 1125.1MB 
[19:29:02]  watch ready 
[ DEBUG! ]  watch callback start, id: 1, isProd: false, event: change, path: 
            /Users/maksymkunytsia/work/paymash/pos/src/pages/settings/settings.page.ts MEM: 1052.0MB 
[19:29:20]  build update started ... MEM: 1052.0MB 
[19:29:20]  transpile update started ... MEM: 1052.0MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 9886 MEM: 1052.1MB 
[ DEBUG! ]  worker created, taskModule: transpile, pid: 9887 MEM: 1052.7MB 
[19:29:20]  transpile update finished in 359 ms MEM: 1052.7MB 
[19:29:20]  rollup update started ... MEM: 1052.7MB 
[ DEBUG! ]  entry: /Users/maksymkunytsia/work/paymash/pos/src/app/main.dev.ts, dest: 
            /Users/maksymkunytsia/work/paymash/pos/www/build/main.js, cache: undefined, format: iife MEM: 1052.7MB 
[ DEBUG! ]  worker exited, taskModule: lint, pid: 9886 MEM: 1118.2MB 
[ DEBUG! ]  worker exited, taskModule: transpile, pid: 9887 MEM: 958.8MB 
[ DEBUG! ]  bundle.modules: 850 MEM: 1018.5MB 
[ DEBUG! ]  Cached module paths: 850, 
            /var/folders/n8/9_st8r097wj6zm06r84gy0lr0000gn/T/usersmaksymkunytsiaworkpaymashpos/modulepaths.json MEM: 
            1018.5MB 
JS changed:   www/build/main.js
[19:29:36]  rollup update finished in 15.95 s MEM: 1342.1MB 
[19:29:36]  build update finished in 16.32 s MEM: 1342.1MB 
[ DEBUG! ]  watch callback complete, id: 1, isProd: false, event: change, path: 
            /Users/maksymkunytsia/work/paymash/pos/src/pages/settings/settings.page.ts MEM: 1342.1MB 
[19:29:36]  watch ready

So HTML updates really fast, but JS...

With webpack i got 'Error: Cannot find module "../../common/services/index/"(…)' in console (barrels doesn't work).

ionic $ [19:33:57]  template update started ... 
[19:33:57]  build update started ... 
[19:33:57]  transpile update started ... 
[19:33:58]  transpile update finished in 763 ms 
[19:33:58]  webpack update started ... 
JS changed:   www/build/main.js
[19:34:04]  webpack update finished in 5.84 s 
[19:34:04]  build update finished in 6.63 s 
[19:34:04]  template update finished in 6.63 s 
[19:34:04]  watch ready 
[19:34:07]  build update started ... 
[19:34:07]  transpile update started ... 
[19:34:07]  transpile update finished in 443 ms 
[19:34:07]  webpack update started ... 
JS changed:   www/build/main.js
[19:34:14]  webpack update finished in 6.54 s 
[19:34:14]  build update finished in 6.98 s 
[19:34:14]  watch ready

maxkunitsa on 1 Nov 2016

@maxkunitsa how many pages does your project have if you dont mind? Also what kind of file are you importing that is throwing that error? Is it a page? Or is it something like a json file?

jgw96 on 1 Nov 2016

@Manduro,

HTML updates and ionic serve updates both only modify the one file and recreate the bundle from that. It should take a handful of seconds at the most. Can you add --debug to the watch npm script and see if there is anything strange there?

My typical first build is ~10 seconds for a 10 page application, then subsequent builds are 2.5-3 seconds every time.

Thanks,
Dan

danbucholtz on 1 Nov 2016

Yestarday I tried app-scripts v0.0.38 and webpack was blazing fast - update of my project took 5-8sec. Today, after installation of v0.0.39 I see big slow down - the same project, the same change in ts file and it takes 14-16sec. Any idea why the slow down?

MarkChrisLevy on 1 Nov 2016

@lleevvyy, yes, we added source maps back in. But it shouldn't have that big of an impact. Do you have an SSD? Hmm, thinking why that would be... I am consistently around 2.5 seconds.

Thanks,
Dan

danbucholtz on 1 Nov 2016

@danbucholtz Yes, I have SSD. Below result of watch script with --debug.

0.0.39:

ionic $ [ DEBUG! ]  watch callback start, id: 0, isProd: false, event: change, path: 
            /Volumes/Project/catalog/app/src/pages/main/main-page.ts  MEM: 780.4MB 
[21:51:58]  build update started ... MEM: 780.4MB 
[21:51:58]  transpile update started ... MEM: 780.4MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 22055  MEM: 780.5MB 
[ DEBUG! ]  worker created, taskModule: transpile, pid: 22058  MEM: 782.1MB 
[21:51:59]  transpile update finished in 526 ms MEM: 782.1MB 
[21:51:59]  webpack update started ... MEM: 782.1MB 
[ DEBUG! ]  webpackUpdate: Typescript File Changed  MEM: 782.1MB 
[ DEBUG! ]  webpackUpdate: Transforming paths  MEM: 782.1MB 
[ DEBUG! ]  webpackUpdate: Writing Files to tmp  MEM: 782.1MB 
[ DEBUG! ]  webpackUpdate: Starting Incremental Build  MEM: 782.1MB 
JS changed:   www/build/main.js
[ DEBUG! ]  worker exited, taskModule: lint, pid: 22055  MEM: 936.6MB 
[ DEBUG! ]  Webpack Bundle Updated  MEM: 936.6MB 
[ DEBUG! ]  handleWebpackBuildSuccess: Resolving with Webpack data  MEM: 936.6MB 
[ DEBUG! ]  webpackUpdate: Incremental Build Done, processing Data  MEM: 938.6MB 
[ DEBUG! ]  Cached module paths: 1083, 
            /var/folders/27/d46m2kjd233dbc152r3j96y80000gn/T/projectcatalogapp/modulepaths.json 
             MEM: 938.6MB 
[21:52:11]  webpack update finished in 12.67 s MEM: 938.6MB 
[21:52:11]  build update finished in 13.21 s MEM: 938.6MB 
[ DEBUG! ]  watch callback complete, id: 0, isProd: false, event: change, path: 
            /Volumes/Project/catalog/app/src/pages/main/main-page.ts  MEM: 938.6MB 

[21:52:11]  watch ready 

[ DEBUG! ]  worker exited, taskModule: transpile, pid: 22058  MEM: 937.6MB

0.0.38:

ionic $ [ DEBUG! ]  watch callback start, id: 0, isProd: false, event: change, path: 
            /Volumes/Project/catalog/app/src/pages/main/main-page.ts  MEM: 764.4MB 
[21:54:32]  build update started ... MEM: 764.4MB 
[21:54:32]  transpile update started ... MEM: 764.4MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 22260  MEM: 764.4MB 
[ DEBUG! ]  worker created, taskModule: transpile, pid: 22261  MEM: 747.2MB 
[21:54:33]  transpile update finished in 501 ms MEM: 747.2MB 
[21:54:33]  webpack update started ... MEM: 747.2MB 
[ DEBUG! ]  webpackUpdate: Typescript File Changed  MEM: 747.2MB 
[ DEBUG! ]  webpackUpdate: Transforming paths  MEM: 746.1MB 
[ DEBUG! ]  webpackUpdate: Writing Files to tmp  MEM: 746.1MB 
[ DEBUG! ]  webpackUpdate: Starting Incremental Build  MEM: 740.2MB 
[ DEBUG! ]  Webpack Bundle Updated  MEM: 437.7MB 
[ DEBUG! ]  handleWebpackBuildSuccess: Resolving with Webpack data  MEM: 437.9MB 
JS changed:   www/build/main.js
[ DEBUG! ]  webpackUpdate: Incremental Build Done, processing Data  MEM: 438.5MB 
[ DEBUG! ]  Cached module paths: 1083, 
            /var/folders/27/d46m2kjd233dbc152r3j96y80000gn/T/projectcatalogapp/modulepaths.json 
             MEM: 438.5MB 
[21:54:40]  webpack update finished in 6.89 s MEM: 438.5MB 
[21:54:40]  build update finished in 7.40 s MEM: 438.6MB 
[ DEBUG! ]  watch callback complete, id: 0, isProd: false, event: change, path: 
            /Volumes/Project/catalog/app/src/pages/main/main-page.ts  MEM: 438.6MB 

[21:54:40]  watch ready 

[ DEBUG! ]  worker exited, taskModule: lint, pid: 22260  MEM: 438.7MB 
[ DEBUG! ]  worker exited, taskModule: transpile, pid: 22261  MEM: 41

MarkChrisLevy on 1 Nov 2016

@danbucholtz Look at memory usage after "Starting Incremental Build" - in 0.0.38 memory usage goes down in 0.0.39 goes up. Hope that helps to trace the problem.

MarkChrisLevy on 1 Nov 2016

@lleevvyy, @Manduro, how old is your computer? What sort of processor, ram, and SSD? Just trying to figure out what could be causing the slowness.

Thanks,
Dan

danbucholtz on 1 Nov 2016

@danbucholtz MacBook Pro, Intel Core i5, 2,53 GHz, 6GB ram, SSD OCZ Vertex2... But, as I wrote - the performance on 0.0.38 was very good and I've made the test again couple of minutes ago. Have you seen my post above (about the difference in memory consumption)? Maybe that is the reason of the slow down?

MarkChrisLevy on 1 Nov 2016

@lleevvyy thanks for all the info! Out of curiosity, how many pages does your app have?

jgw96 on 1 Nov 2016

@lleevvyy, It makes sense to me that it is a little slower since we enabled a devtool of source-maps which is the slowest-but-best sourcemap webpack offers. See the configuration info here. One can provide their own webpack config and change this value if they'd like. See how to do that here.

I wouldn't expect it to be 2x slower, though. I am on a 16GB MBP 15", the most recent one, and no matter what I do when building out an app, I see 2.5 seconds. So I see basically zero difference on my machine between 0.0.38 and 0.0.39 in both a blank starter app being built out, and then our pretty large conference app example as seen here.

Is anyone else seeing really slow build times? @mirkonasato, any thoughts on why that might be?

Thanks,
Dan

danbucholtz on 1 Nov 2016

@jgw96 8 pages, but quite complex, lots of other ts files, over 10k LOC (excluding scss and html) and few dependencies to js libraries.

MarkChrisLevy on 1 Nov 2016

@danbucholtz Yup, it is because of devtool=source-maps... When I disable it, the times of webpack update are the same as in 0.0.38... Understand, that you cannot do too much with it, so I will override it in my webpack config. Thanks.

Ps. Well, I wanted to buy a brand new MBP, but not happy with the changes that Apple made few days ago.. Still, hardware refreshment is required in my case :-)

MarkChrisLevy on 1 Nov 2016

@lleevvyy good find! Yeah we are working on using the TypeScript source maps instead of the webpack ones which should fix this (: Thanks for all the debugging

jgw96 on 1 Nov 2016

@danbucholtz @jgw96 Thanks! Great job!

MarkChrisLevy on 1 Nov 2016

Just to confirm, 0.0.38 is faster on my machine as well. After a ts change 0.0.38 rebuilds in 1.1-1.2 seconds, with 0.0.39 it goes up to 2.8-2.9 seconds.

And yes I believe the devtool alone can explain the difference. With e.g. devtool: 'eval-source-map' it's pretty much as fast as 0.0.38.

(What's strange is that I don't see the original typescript code, not even with devtool: 'source-map', but that's a separate thing.)

mirkonasato on 1 Nov 2016

@mirkonasato, in order to support roll-up too, we do the typescript stuff outside of the context of webpack. We have the actual Typescript source code and map available in memory so in version 0.0.40 we are mapping back to that. Seeing some weird results when used in conjunction with AoT right now, though.

I'm glad to here it's still very fast for you. I was worried there for a second. Thanks for testing! 💯

Thanks,
Dan

danbucholtz on 2 Nov 2016

👍1

@danbucholtz @jgw96
Big tnx for replying and attempts to understand 👍
My app: 10 pages, ~ 25 services, ~ 20 classes, ~15 common components used in pages, html/css for each page/component.
My MacBook Pro: Intel Core i5, 2,6 GHz, 8GB DD3 ram, 256 GB SSD

Rollup:
JS: 5-8 seconds for build with 0.0.30 and 15-20 seconds with 0.0.38/0.0.39.
HTML: 5-8 seconds with 0.0.30 and 100-500 ms with 0.0.38/0.0.39.

Webpack
JS: 5-8 seconds for build with 0.0.39
HTML: 300ms - 800ms for build with 0.0.39
but i have error 'Error: Cannot find module "../../common/services/index/"(…)' in console (barrels doesn't work). This file is barrel, something like this:

export * from './utils/color.utils';
export * from './utils/localstorage.utils';
export * from './utils/math.utils';
export * from './utils/uuid.utils';

maxkunitsa on 2 Nov 2016

@danbucholtz Sure, below are my logs.
App info: ~25 pages, ~100 ts files, multiple dependencies.
Hardware (2010): i5-520M Arrandale, 8GB memory, SATA300 SSD.

Nothing crazy in the logs. Maybe it's just the sourcemap taking much longer on a larger app?

Debug logs:
Initial build ~50s (shows some weird double paths)

[09:18:38]  ionic-app-scripts 0.0.39 
[09:18:38]  watch started ... MEM: 110.7MB 
[09:18:38]  build dev started ... MEM: 110.7MB 
[09:18:38]  clean started ... MEM: 110.7MB 
[ DEBUG! ]  clean /Users/user/path/www/build  MEM: 110.7MB 
[09:18:38]  clean finished in 3 ms MEM: 110.8MB 
[09:18:38]  copy started ... MEM: 110.8MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 1684  MEM: 111.0MB 
[09:18:38]  transpile started ... MEM: 111.0MB 
[09:18:39]  lint started ... 
[09:18:51]  transpile finished in 12.86 s MEM: 269.7MB 
[09:18:51]  webpack started ... MEM: 269.7MB 
[ DEBUG! ]  Wrote .js files to disk  MEM: 270.8MB 
[ DEBUG! ]  Starting Webpack watch  MEM: 270.9MB 
[09:18:52]  copy finished in 13.94 s MEM: 275.9MB 
[09:19:17]  lint finished in 37.84 s 
[ DEBUG! ]  worker exited, taskModule: lint, pid: 1684  MEM: 714.3MB 
[ DEBUG! ]  Webpack Bundle Updated  MEM: 714.3MB 
[ DEBUG! ]  handleWebpackBuildSuccess: Resolving with Webpack data  MEM: 714.3MB 
[ DEBUG! ]  Cached module paths: 1308, 
            /var/folders/pr/ck8q921d21j8y6d5pmqy4z1c0000gn/T/usersjobdwvdfellofelloclient/modulepaths.json  MEM: 
            715.0MB 
[09:19:23]  webpack finished in 31.94 s MEM: 715.0MB 
[09:19:23]  sass started ... MEM: 715.0MB 
[ DEBUG! ]  sass outFile: /Users/user/path/www/build/main.css  MEM: 715.0MB 
[ DEBUG! ]  sass includePaths: 
            /Users/user/path/src,node_modules/ionic-angular/themes,node_modules/ionicons/dist/scss 
             MEM: 715.0MB 
[ DEBUG! ]  sass moduleDirectories: 244  MEM: 715.0MB 
[ DEBUG! ]  sass userSassVariableFiles: 1  MEM: 714.4MB 
[ DEBUG! ]  sass componentSassFiles: 157  MEM: 714.4MB 
[ DEBUG! ]  sass, start postcss/autoprefixer  MEM: 766.0MB 
[ DEBUG! ]  sass: postcss/autoprefixer completed  MEM: 741.9MB 
[ DEBUG! ]  sass start write output: /Users/user/path/www/build/main.css  MEM: 741.9MB 
[ DEBUG! ]  sass saved output: /Users/user/path/www/build/main.css  MEM: 743.1MB 
[09:19:27]  sass finished in 4.18 s MEM: 743.1MB 
[09:19:27]  build dev finished in 49.01 s MEM: 743.1MB 
[ DEBUG! ]  watcher ready: 
            /Users/user/path/Users/user/path/src/assets/,/Users/user/path/src/index.html,/Users/user/path/src/manifest.json,/Users/user/path/src/service-worker.js,node_modules/ionic-angular/polyfills/polyfills.js,node_modules/ionicons/dist/fonts/
             MEM: 743.8MB 
[ DEBUG! ]  watcher ready: 
            /Users/user/path/Users/user/path/src/assets/,/Users/user/path/src/index.html,/Users/user/path/src/manifest.json,/Users/user/path/src/service-worker.js,node_modules/ionic-angular/polyfills/polyfills.js,node_modules/ionicons/dist/fonts/
             MEM: 743.8MB 
[ DEBUG! ]  watcher ready: 
            /Users/user/path/Users/user/path/src/assets/,/Users/user/path/src/index.html,/Users/user/path/src/manifest.json,/Users/user/path/src/service-worker.js,node_modules/ionic-angular/polyfills/polyfills.js,node_modules/ionicons/dist/fonts/
             MEM: 743.8MB 
[ DEBUG! ]  watcher ready: /Users/user/path/Users/user/path/src/**/*.html  MEM: 
            743.8MB 
[ DEBUG! ]  watcher ready: /Users/user/path/Users/user/path/src/**/*.ts  MEM: 
            743.8MB 
[ DEBUG! ]  watcher ready: /Users/user/path/Users/user/path/src/**/*.scss  MEM: 
            743.8MB 
[ DEBUG! ]  watcher ready: /Users/user/path/Users/user/path/src/**/*  MEM: 
            743.8MB 
[09:19:29]  watch ready in 51.27 s MEM: 743.8MB

TS file update: ~5-25 seconds, generally ~15.

[ DEBUG! ]  watch callback start, id: 0, isProd: false, event: change, path: 
            /Users/user/path/src/pages/network/network.ts  MEM: 743.9MB 
[09:23:58]  build update started ... MEM: 743.9MB 
[09:23:58]  transpile update started ... MEM: 743.9MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 1791  MEM: 743.6MB 
[ DEBUG! ]  worker created, taskModule: transpile, pid: 1793  MEM: 743.7MB 
[09:23:59]  transpile update finished in 309 ms MEM: 743.7MB 
[09:23:59]  webpack update started ... MEM: 743.7MB 
[ DEBUG! ]  webpackUpdate: Typescript File Changed  MEM: 743.7MB 
[ DEBUG! ]  webpackUpdate: Transforming paths  MEM: 743.7MB 
[ DEBUG! ]  webpackUpdate: Writing Files to tmp  MEM: 743.7MB 
[ DEBUG! ]  webpackUpdate: Starting Incremental Build  MEM: 743.7MB 
[ DEBUG! ]  worker exited, taskModule: lint, pid: 1791  MEM: 673.3MB 
[ DEBUG! ]  worker exited, taskModule: transpile, pid: 1793  MEM: 673.3MB 
JS changed:   www/build/main.js
[ DEBUG! ]  Webpack Bundle Updated  MEM: 673.3MB 
[ DEBUG! ]  handleWebpackBuildSuccess: Resolving with Webpack data  MEM: 673.3MB 
[ DEBUG! ]  webpackUpdate: Incremental Build Done, processing Data  MEM: 671.6MB 
[ DEBUG! ]  Cached module paths: 1308, 
            /var/folders/pr/ck8q921d21j8y6d5pmqy4z1c0000gn/T/usersuserpath/modulepaths.json  MEM: 
            671.6MB 
[09:24:13]  webpack update finished in 14.68 s MEM: 671.6MB 
[09:24:13]  build update finished in 15.00 s MEM: 671.6MB 
[ DEBUG! ]  watch callback complete, id: 0, isProd: false, event: change, path: 
            /Users/user/path/src/pages/network/network.ts  MEM: 671.6MB 

[09:24:13]  watch ready

HTML file update:

[ DEBUG! ]  watch callback start, id: 1, isProd: false, event: change, path: 
            /Users/user/path/src/pages/network/network.html  MEM: 671.6MB 
[09:25:35]  template update started ... MEM: 671.6MB 
[ DEBUG! ]  templateUpdate, event: change, path: /Users/user/path/src/pages/network/network.html  
            MEM: 671.6MB 
[ DEBUG! ]  templateUpdate: updating webpack file  MEM: 671.6MB 
[09:25:35]  build update started ... MEM: 671.6MB 
[09:25:35]  transpile update started ... MEM: 671.6MB 
[ DEBUG! ]  worker created, taskModule: lint, pid: 1834  MEM: 671.6MB 
[ DEBUG! ]  worker created, taskModule: transpile, pid: 1835  MEM: 671.6MB 
[09:25:35]  transpile update finished in 224 ms MEM: 671.6MB 
[09:25:35]  webpack update started ... MEM: 671.6MB 
[ DEBUG! ]  webpackUpdate: Typescript File Changed  MEM: 671.6MB 
[ DEBUG! ]  webpackUpdate: Transforming paths  MEM: 671.6MB 
[ DEBUG! ]  webpackUpdate: Writing Files to tmp  MEM: 671.6MB 
[ DEBUG! ]  webpackUpdate: Starting Incremental Build  MEM: 671.6MB 
[ DEBUG! ]  Webpack Bundle Updated  MEM: 589.5MB 
[ DEBUG! ]  handleWebpackBuildSuccess: Resolving with Webpack data  MEM: 589.5MB 
[ DEBUG! ]  webpackUpdate: Incremental Build Done, processing Data  MEM: 591.6MB 
[ DEBUG! ]  Cached module paths: 1308, 
            /var/folders/pr/ck8q921d21j8y6d5pmqy4z1c0000gn/T/usersuserpath/modulepaths.json  MEM: 
            591.6MB 
[09:25:42]  webpack update finished in 6.85 s MEM: 591.6MB 
[09:25:42]  build update finished in 7.08 s MEM: 591.6MB 
[09:25:42]  template update finished in 7.08 s MEM: 591.6MB 
[ DEBUG! ]  watch callback complete, id: 1, isProd: false, event: change, path: 
            /Users/user/path/src/pages/network/network.html  MEM: 591.6MB 

[09:25:42]  watch ready 

[ DEBUG! ]  worker exited, taskModule: lint, pid: 1834  MEM: 591.6MB 
[ DEBUG! ]  worker exited, taskModule: transpile, pid: 1835  MEM: 591.6MB

SASS update:

[ DEBUG! ]  watch callback start, id: 2, isProd: false, event: change, path: 
            /Users/user/path/src/theme/fonts.scss  MEM: 591.6MB 
[09:27:08]  sass update started ... MEM: 591.6MB 
[ DEBUG! ]  sass outFile: /Users/user/path/www/build/main.css  MEM: 591.6MB 
[ DEBUG! ]  sass includePaths: 
            /Users/user/path/src,/Users/user/path/src,node_modules/ionic-angular/themes,node_modules/ionicons/dist/scss
             MEM: 591.6MB 
[ DEBUG! ]  sass moduleDirectories: 244  MEM: 591.6MB 
[ DEBUG! ]  sass userSassVariableFiles: 1  MEM: 591.6MB 
[ DEBUG! ]  sass componentSassFiles: 157  MEM: 591.6MB 
[ DEBUG! ]  sass, start postcss/autoprefixer  MEM: 622.5MB 
[ DEBUG! ]  sass: postcss/autoprefixer completed  MEM: 616.8MB 
[ DEBUG! ]  sass start write output: /Users/user/path/www/build/main.css  MEM: 616.8MB 
CSS changed:  www/build/main.css
[ DEBUG! ]  sass saved output: /Users/user/path/www/build/main.css  MEM: 611.7MB 
[09:27:11]  sass update finished in 3.61 s MEM: 611.7MB 
[ DEBUG! ]  watch callback complete, id: 2, isProd: false, event: change, path: 
            /Users/user/path/src/theme/fonts.scss  MEM: 611.7MB 

[09:27:11]  watch ready

Manduro on 2 Nov 2016

@maxkunitsa, can you open a separate issue for that? We'll get it fixed.

@Manduro, if the build is taking too long, the best bet may be to override the webpack.config.js by following the docs here and providing a devtool value of eval. That will speed things up but the source maps will be lower quality and won't work as well.

Thanks,
Dan

danbucholtz on 2 Nov 2016

👍1

Hi guys. I figured out that node version v5.11.1 is much faster than version v6.7.0 for mac users. what versions are you guys using?

pascalwhoop on 5 Nov 2016

@pascalwhoop tried node 7.0.0, 5.11.1 and 6.9.1 no any difference.

maxkunitsa on 5 Nov 2016

Tried everything, but nothing worked.
I've finally updated app-scripts to 0.0.39 (was 0.0.36) and there is a huge improvement for both windows and Ubuntu. From ~30/40sec for every modification on a source file to ~10sec.
"ionic run" is also faster.
This worked for me:
npm install @ionic/app-scripts@latest --save-dev

Weezlo on 6 Nov 2016

The watch is significant faster now, so I am going to close this issue for now. I consistently see builds between 750-1500ms. We have a few more optimizations we'll make over the coming weeks as well.

Thanks,
Dan

danbucholtz on 10 Nov 2016

👍3

@danbucholtz Thank you very, very much for your work!!!! I can confirm, that it is lightning fast with latest releases.

MarkChrisLevy on 10 Nov 2016

👍2

@lleevvyy, really happy to hear that! 😄 . We have a few more optimizations in mind that we'll give a try in the coming weeks.

Thanks,
Dan

danbucholtz on 11 Nov 2016

@danbucholtz Thanks a lot for all the work you are putting in!! Things have certainly improved A LOT :)

Manduro on 11 Nov 2016

Yes. but for me right now the fastest version remains 0.0.38 with about 1.2 s build time. The latest one takes about 4-5 seconds.

raducostea on 11 Nov 2016

@danbucholtz Not fast, blazing fast! I'm having a 600% (Yep, 6 hundred) improvement from that buggy 0.38 to the latest. Out-stand-ing.

devarg on 12 Nov 2016

Is it just me or 0.0.47 seems about twice as slow compared to 0.0.46?

mirkonasato on 14 Dec 2016

@mirkonasato,

We reverted back to source-map instead of eval for the webpack devtool. You can change it back by setting ionic_source_map_type in the package.json config. I personally prefer the faster speeds to an original, high quality source map but the team decided to go with the better map.

Thanks,
Dan

danbucholtz on 14 Dec 2016

@danbucholtz thanks, but there other options available that offer a better speed/quality tradeoff for development. Webpack 2 defaults to eval-cheap-module-source-map.

(And eval doesn't seem to be working properly anyway, but that's a separate issue.)

mirkonasato on 15 Dec 2016

@mirkonasato,

Believe me, I exhaustively looked into the options and was very disappointed to see breakpoints not work correctly, get hit at wrong times, etc. eval and source-map worked best for us. I am very open to changing this if it works correctly.

What isn't working with eval? I have used the eval maps successfully in testing. Was able to set and hit breakpoints as expected, etc.

Thanks,
Dan

danbucholtz on 15 Dec 2016

@danbucholtz eval actually works fine, sorry. Just have to close and re-open the app after changing source map type, otherwise Chrome somehow gets confused.

I'd just like a devtool option that shows file and line number in the DevTools console rather than something like VM1470:18.

mirkonasato on 15 Dec 2016

can u please tell me which package.json to change the
ionic_source_map_type
to
eval

@mirkonasato @danbucholtz

i cant find any of this settings
package.json in project folder or some where else

i added this to package.json of project folder
"IONIC_SOURCE_MAP_TYPE": "eval",
but with no improvement in performance

mohamedsharaf on 3 Jan 2017

...
"config" : {
   "ionic_source_map_type" : "eval"
}
...

To be clear, config is a root node. It should result in a faster development build.

Thanks,
Dan

danbucholtz on 4 Jan 2017

thx 2 or 3 second faster

[05:19:15] build started ...
[05:19:15] transpile update started ...
[05:19:15] transpile update finished in 83 ms
[05:19:15] webpack update started ...
[05:19:20] webpack update finished in 5.25 s
[05:19:22] build finished in 7.41 s

mohamedsharaf on 5 Jan 2017

I'm currently using @ionic/app-scripts v1.3.7 and my webpack update is taking over 45 seconds to complete 😢

sean-hill on 1 Jun 2017

@sean-hill,

How do I recreate? That seems strange to me. Can you dive in and provide more info. Maybe open another issue with some details.

Thanks,
Dan

danbucholtz on 28 Jun 2017

Ionic-app-scripts: Watching is slow

Most helpful comment

All 78 comments

Related issues