Rebuild time grew 50% after updating to 1.2 #5269
Comments
|
Things to do if you want to improve your report:
|
|
Here you go: As you can see, I dont have Browserify added, so I have no idea why it's mentioned during build time. Here are my files:
|
|
@avalanche1 please, post the output of |
|
I've actually managed to significantly improve build time by deleting And I don't know how to copy profiling results after |
|
My rebuild time has gone from 5s to 7s (Win 7) when changing a client-side js file. Packages: Files, excluding
Files, including
|
|
The build time has also roughly doubled for me on OSX, if I'm understanding the |
|
On OSX compiling is orders of magnitude slower. Without going back and checking - because it's so much slower that it's really obvious . Building Yup, that's Total: 152621.5. Note: a package we're using is installing cosmos:browserify as a dependency. We're in the process of removing that, so we'll see if that's the real culprit. |
|
Can confirm that this is very slow on 1.2 on OSX Yosemite. The most egregious are when modifying client files. Packages: Profiling from initial app run After modifying a client file (note, it takes ~10 seconds before the profiling output even begins) |
|
Some for me on Yosemite. I wish I hadn't updated to Meteor 1.2 this early. :-/ |
|
Remember that you can develop in previous version with |
|
Yep, I've already downgraded to 1.1.0.3 for now. Unfortunately, Jasmine is not working there due to another bug in the build tools. That's the main reason why I wanted to upgrade. But for now, I'm staying on 1.1.0.3 until the problems have been addressed. |
|
I noticed a massive build time difference depending on what's in Rebuild time without private dir present: 786ms Note, in this case the private dir is pretty big... but, why should untouched files influence rebuild time? In both cases though package selection is still 2.5s - 5s :( This is for the same change... i.e. no Running Meteor 1.2.0.2. |
|
@gadicc this is an interesting observation. What kind of files do you have in private and what are the packages you are using? When I was benchmarking one of the real apps, the build time was long because the private folder contained a lot of unused JSON files that were huge in size. And because there was some package that mindlessly was reading every JSON file, the build tool would "re-compile" huge JSON files without a reason. |
@aaronjudd, did you find who depends on cosmos:browserify? Did you succesfully remove the dependency? |
|
@steph643 |
|
Yes, and manually updating to the latest version of browserify doesn't improve rebuild time. |
|
Re: (unchanged) contents of private/ affecting rebuild time
No packages beyond the defaults from Repro and full logs: https://github.com/gadicc/meteor-private-bench Note: I never actually checked if this was an issue pre 1.2, or checked the (And yeah, untamed packages can do some crazy things sometimes :)). |
|
Btw, I have seen a noticeable increase in 1.2 as well – roughly guessing: Twice as slow, but I didn't know of the Lots of files in this project (290
Notes
Here are the outputs from my Meteor 1.1.0.3Initial StartupOn File ChangeMeteor 1.2.0.2Initial StartupOn File ChangeSo yea, whether it's a package doing something or not, it's definitely doing it slower in 1.2. Hope this helps. |
|
I've noticed that the problem is it's not entirely related to things being slower, but that it also slows down over time. If I stop and restart the meteor process things are markedly better. Look at this CPU graph where I am repeatedly making small changes to trigger a build.
|
|
I'm also seeing slow builds after upgrading to Meteor 1.2. I'm working on a large project that uses ~50 local packages and a number of external packages. Here's my profiling output from making a small change to a client-side template and my .meteor/versions: https://gist.github.com/benweissmann/576b1453de226c33a10f I'm running inside Vagrant. The guest machine is ubuntu 14.04; the host is OSX 10.10. Files are shared via NFS with cachefilesd running inside Vagrant. |
|
Bummer! This hangs for us as well with approx same extra duration :( Anyone from |
|
Am having issues with this as well. |
|
+1 |
|
For those of you on Windows, please try disabling your antivirus software and see if this helps to speed up anything. Posting this per #5691. Also, to figure out if this is a problem on your OS/Hardware configuration or project, you can try cloning https://github.com/wekan/wekan which is fast on refreshes (per mquandalle). If that project is slow to rebuild on your machine, it could be something specific to your setup that we missed. |
|
Well after all, Wekan isn’t that fast to refresh on my computer (I thought so because I have automatized the process of writing relatively large bunches of code, save all files at once, and wait a few seconds before looking at the browser). My complete reload time results are here and at first glance they are consistent with what other have observed. |
|
@mquandalle I worked on more profiling on Wekan specifically, and I noticed that a big chunk of recomputation is spent on styl and i18n.json files. Those use old-style build plugins w/o caching: Update: this is like 45% of build time spent on a client-side file update on my machine |
|
Hmm, I have stylus plugin loaded also. Rebuild times keep growing perpetually until I need to restart server. There is a leak someplace. |
|
Perpetual growth over time is definitely the trend for us. A little more worryingly, I've started to notice the meteor node process hang at 100% cpu - properly hang, as in for 5 mins plus - while rebuilding requiring a kill -9 to get things running again. Happy to post more info as required, just ask. |
|
Looking at Wekan, here are the things that stood out to me changing client-side file (running from checkout sha 482111f):
|
|
Didn’t realize the raw numbers of time spent the on legacy compiler API! I will work on that (and I have a pretty good incentive to do it quickly :-)). |
|
Oh I guess the |
+1 Can confirm this problem, having this once in a while. It usually happens if I do code changes in quick succession. Seems as if Meteor gets a hiccup then. Won't react on ^C any more, only killing the process helps. |
Following a valuable comment from @Slava [0], this commit improves the build and the reload time of Wekan. It does so by implementing the following changes: * Upgrade the meteor build tool to a version which includes a fix to an issue with the caching of the dependency resolution [1]. This fix will be included in Meteor 1.3, so we won't have to use a "special release" anymore; * Change the stylus package from `mquandalle:stylus` to `stylus` as we don't use the libraries included with my (mquandalle) version like Jeet or Rupture, and the core package implement the new meteor build plugin API with caching. The generated CSS file is slighly different mostly mostly because we miss some autoprefixed values but even until meteor-core figure out a good way to configure CSS autoprefixing, the benefits (better compile time) outweights the cons. For record I attached a diff in the generated style [2]; * Upgrade `mquandalle:jade` to a version that implements the build plugin caching correctly. These 3 changes decrease the reload time of about 50% on my computer. [0]: meteor/meteor#5269 (comment) [1]: meteor/meteor#5747 [2]: https://gist.github.com/mquandalle/e95198626767b56fc63a
|
I'm going to close this relatively old issue. I don't believe this issue is providing any value any more as it is as most conversation on this topic takes place in other issues now. Build times were a major focus on Meteor 1.4.2 and I believe they have improved in that release. I'm closing this in favor of the newer issues with more relevant reproductions and current use-cases. |
_1 Upvote_ It now loads compileLessBatch, compile-ecmascript, CosmosBrowserify, builds for web.cordova.
Refresh time grew accordingly.
I'm on win7, btw.
The text was updated successfully, but these errors were encountered: