Webdev serve - Time consuming

[JeromePuttemans]

Hello, I’m opening this issue because I’m really confused about the time wasted switching to dart2. Indeed, I work hard to migrate a big project from dart1. The project has around thirty sub-projects and each tiny change in a sub-project in the hierarchy requires a recompilation before I can see the result in the browser. Even a simple little ‘;’ takes monster time. We cannot afford to wait 5-10 minutes for the slightest change even with the automatic re-build of

webdev serve

Also, in its time, debugging was relatively fast via chromium because there was no compilation. Now, using webstorm, the stacktrace is abominable because it only fatally shows incomprehensible javascript.

Seriously, when you work in a project without any other dependence, no worries, it's great ! But in a big project like ours, it's a real calamity.

How do you manage this ?

Unless I miss something, are there ways to speed up the process?

Currently it is a totally indigestible process.

update : dart --version Dart VM version: 2.7.1 (Thu Jan 23 13:02:26 2020 +0100) on "windows_x64" (Windows 10)

Thank u !

[supermuka]

What OS and Dart 2 version are you using?

[JeromePuttemans]

Dart VM version: 2.7.1 (Thu Jan 23 13:02:26 2020 +0100) on "windows_x64" (Windows 10)

[supermuka]

Dart webdev \ build_runner had an issue on Windows until a few versions ago.

Details: https://github.com/dart-lang/tools/issues/1713 and https://github.com/dart-lang/webdev/issues/436

My team particularly suffered a lot from this Windows performance issue. But now is working fine.

I am not using the last versions. My current configuration is (related OS and packages for this issue):

Windows 10 x64 Dart SDK 2.7.0 build_runner 1.8.0 build_web_compilers 2.9.0 webdev 2.5.4

[JeromePuttemans]

Thank u, I updated the packages like yours, mine where :

build_runner: 1.7.3 build_web_compilers: 2.8.0 webdev 2.5.4

Well, it seems to be a little better but what is very disappointing is the time it takes (7m 57s !) to build all the stuff before being ready to test in the root project each time a small change is made in a sub-sub-project...

[INFO] Running build completed, took 7m 57s
[INFO] Caching finalized dependency graph completed, took 1.4s
[INFO] Succeeded after 7m 59s with 2787 outputs (1914 actions)

[supermuka]

The first time the compilation is ran (when it has not yet been compiled, when there is a significant change in the version of sdk / packages, etc.). The time is long.

But after the first time, any changes are compiled very quickly.

In one of the my projects, to your benchmarking (Windows 10, 2 core i7, 8GB):

1. First time.

[INFO] Running build completed, took 4m 45s [INFO] Caching finalized dependency graph completed, took 750ms [INFO] Succeeded after 4m 45s with 6883 outputs (15228 actions)

2. Small code change.

[INFO] Updating asset graph completed, took 17ms [INFO] Running build completed, took 17.4s [INFO] Caching finalized dependency graph completed, took 569ms [INFO] Succeeded after 18.0s with 12 outputs (11 actions)

Some things I have to pay attention to to execute a compilation well:

1. I try to respect the guide to directory structure to Dart project, specially put all "private code" into lib/src. See https://dart.dev/guides/libraries/create-library-packages

2. I frequently delete all files into C:\Users\MyAccount\AppData\Local\.dartServer. When have a lot subdirectories and files into this directory, mainly Analyser could be slow.

3. First time compilation or when there is version change in SDK or packages, I normally delete all directories build or build_resolves into .dart_tool under the project directory.

[jakemac53]

You may also want to make sure you are only serving the web directory, and not the test directory. Otherwise we will also be rebuilding all your tests on each change which isn't necessary.

1. I try to respect the guide to directory structure to Dart project, specially put all "private code" into lib/src. See https://dart.dev/guides/libraries/create-library-packages

This is one of the most impactful things you can do. If you put everything under lib and not lib/src then you get a ton of small modules and it increases the overhead a lot.

You should also avoid imports directly into lib/src from other packages, which can also lead to unexpected behavior (and isn't recommended anyways).