In the first phase - ProjectContext prepareProjectForBuild - it seems that _resolveConstraints (particularly generate constraints and sqlite query) takes huge amount of time (264 ms => 18,267 ms) in 1.4.2 compared to 1.4.0.1. Note that I did run the app after upgrading, then killed it, purged disk cache and ran it again, reporting that last run in the benchmark.
The second phase is actually a bit faster on 1.4.2 beta, so that part is good .
One update. running the app now, without purging disk caches, resulted in faster initial build, faster than with 1.4.0.1 (5 seconds and 18 seconds respectively for both phases).
I’m not trying to be negative here, but even if these % improvements are so great. Wouldn’t it all be a lost cause if it still takes 10s or more for every rebuild? People will just start moving to Webpack and alikes anyway? (10s is a lot… especially when you’re writing html).
Currently it takes 2-5 seconds for a rebuild for my not-so-small app (depending on whether I change shared server & client code or only templates/stylesheets). So 3-4 seconds on average is not that bad
Well, if build time drops to 2-3 sec, it will be just a bit longer than my approximate webpack rebuilds. (1.5 sec)
Maintaining webpack along with app is thing I wouldn’t want to do.
True and agreed. I’m just worried that the relative gain (e.g. x2) is too low. In my case some rebuilds take more than 20 seconds, so x2 would mean 10s. And that’s with a ssd even. But I’ll try it first, before worrying
I just saw one thing which would cut my rebuild times by 80%:
The “Checking for missing packages / versions” routine.
Seriously, that one takes way longer than the actual build, at least for me. I also don’t think that packages go missing / are updated since the last build from one minute ago.
Which reminds me: What exactly is the rationale to put all UI stuff into the /imports-folder and not somewhere into client? Because the latter only necessitates a reload on the client (and not all of the time). The former triggers a full-server rebuild which takes way longer.
I’m not seeing the big advantage here and it’s also not documented anywhere.
Note that ‘client’ and ‘imports’ may be combined. Anything under ANY imports directory is lazy loaded. Anything under ANY client directory should only be loaded on the client (same thing for server directories). The directory doesn’t have to be at the top level.
So, theoretically, you’re welcome to use ‘imports/client’ or ‘client/imports’ for the same effects.
I’ve measured the speed improvements again on beta 13, this time on the todos app. Here are the results (in all cases I did all actions twice and recorded 2nd result):
For me, most of the time the build tool is taking care of a client side change.
So i have gone from “much too long”, to quasi instantaneous.
Cold start is still long, but we can live with it.
Great work Ben !
.