Watching is slow #47
Comments
|
Please see #44 This should ease up the watches memory usage and speed it up a bit. |
|
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! |
|
Closed via #44 This should be fixed in the next release of app scripts. |
|
Even with the above fix and |
|
@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. |
|
@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 |
|
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. |
|
@mhartington Thanks for reopen. Below some logs from -- initial build -- -- after one letter change in .ts file -- 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 microsoft/TypeScript#10018 (comment). The other issue is rollup, which takes 16 seconds. |
|
I have same issues as described early by other colleagues. For example: [20:13:47] typescript compilation started ... With beta.11 i had watch timing between 1-2.5 s. |
|
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 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? |
|
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. |
|
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 ... |
|
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. |
|
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. 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. |
|
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 (microsoft/TypeScript#10018 (comment)) 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)? |
|
...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? |
|
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 |
|
@ionic/app-scripts": "0.0.23" did work with "allowJs": true but "0.0.29" resulting now in SyntaxError: Unexpected character '@' |
|
@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 |
|
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 ;) |
|
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
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 |
|
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 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. |
|
when I development some time it take over 100 second for build |
|
@jgw96 8 pages, but quite complex, lots of other ts files, over 10k LOC (excluding scss and html) and few dependencies to js libraries. |
|
@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 :-) |
|
@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 |
|
@danbucholtz @jgw96 Thanks! Great job! |
|
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. (What's strange is that I don't see the original typescript code, not even with |
|
@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 I'm glad to here it's still very fast for you. I was worried there for a second. Thanks for testing! 💯 Thanks, |
|
@danbucholtz @jgw96 Rollup: Webpack |
|
@danbucholtz Sure, below are my logs. Nothing crazy in the logs. Maybe it's just the sourcemap taking much longer on a larger app? Debug logs: TS file update: ~5-25 seconds, generally ~15. HTML file update: SASS update: |
|
@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 Thanks, |
|
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 tried node 7.0.0, 5.11.1 and 6.9.1 no any difference. |
|
Tried everything, but nothing worked. |
|
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, |
|
@danbucholtz Thank you very, very much for your work!!!! I can confirm, that it is lightning fast with latest releases. |
|
@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, |
|
@danbucholtz Thanks a lot for all the work you are putting in!! Things have certainly improved A LOT :) |
|
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. |
|
@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. |
|
Is it just me or |
|
We reverted back to Thanks, |
|
@danbucholtz thanks, but there other options available that offer a better speed/quality tradeoff for development. Webpack 2 defaults to (And |
|
Believe me, I exhaustively looked into the options and was very disappointed to see breakpoints not work correctly, get hit at wrong times, etc. What isn't working with Thanks, |
|
@danbucholtz I'd just like a |
|
can u please tell me which package.json to change the i cant find any of this settings i added this to package.json of project folder |
To be clear, Thanks, |
|
thx 2 or 3 second faster [05:19:15] build started ... |
|
I'm currently using |
|
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, |
and others
Watching has slowed down a lot using the new npm scripts. Below are samples of the time watching takes. 29 seconds is a very long wait for livereloading. The gulp task took about 3 seconds. I'm hoping there's still a lot to improve here!
Are there some config settings we can override to improve speed, until the default situation improves?
Start watch: 46 seconds
Livereload: 29 seconds
The text was updated successfully, but these errors were encountered: